Separation of Concerns

Working by the “scrum book”, sprint is also a release unit, in which you want to complete all the effort you committed to your clients and demonstrate it at the end of the sprint. Well, not in my book. Sprint should be remained an internal unit of time. Sprint is used for planning, for doing and for reflection, to make the team work better over time. It doesn’t mean that your customers will enjoy adjusting to your schedule.

I prefer to leave release cycles outside, as they are external unit of time. You need to adjust them to your customers, not the other way around.

Let’s say that you picked 3 weeks as a sprint size after considering “big enough, small enough” values. If you tie sprint and release together, that means that your clients will see things every 3 weeks. That might be fine, but it won’t allow you to challenge yourself to reduce release cycles. Even worst, the customers might demand a shorter release cycle to earn confidence in your delivery. A dangerous move, in my opinion, is to reduce the sprint size to match desired release cycle. This move might violate the “sprint should be big enough to avoid unacceptable overhead of planning/reflection” principle. Yes, your customers will be happy but your developers won’t. It won’t last. You want both internal team and external customers to be happy and enjoy a process that pushes them forward rather than pushes them around.

What is a Version?

Version is just a bunch of capabilities with a specific target date attached to it. Version is easy to communicate out: “we plan to allow a user to upload image, crop it and update his profile image in version 1.1, which is targeted to July 20th”. Basically, for each targeted date you specify a list of features, enhancements, reports etc. The customers gets to say when the versions should be aimed for, according to their needs.

What does it mean about Sprint Demo then?

Well, if the release cycles are shorter than sprint cycles then the Sprint Demo will become a show off by the team to each other rather to your customers. Obviously, you may want to add another “Release Demo” meeting for your customers (and maybe include the team in it). By doing Sprint Demo internally, the teams will get the chance to see what’s going on “on the other side of the corridor”. Oh, did I mention that this is also fun? It allows the organization to collect valuable internal feedback to make sure our users will love our product as much people who wrote it!

“Sprint” – what does it mean?

Note: my definition of sprint is not by the book. It’s perfectly fine by me as I love adjusting theory to practice; I hope it is okay with you as well. Basically, a sprint is just a time window that you plan to achieve something at. Just imagine a box with your interesting “todo” notes. For example, in the next 2 weeks you may want to plan to perform some proof of concept for your initiative; plan to create 3 landing pages to check which one covert users better to registered users; plan to write a tutorial or even plan to upgrade your team’s computers.

Why do I need to define a specific time window then?

The idea of a sprint, in essence, is simply to (1) ease psychological acceptance of changes and (2) allow shorter, just-in-time planning.

Specific time window, made constant (sprint after sprint), allows you to understand that things might change and you now made mental and physical “room” to adjust when needed. It’s a bit of sugarcoating, of course, but it’s making the transition smoother.

The just-in-time planning part is more “acceptable” when you’re embracing the fact that it’s too damn expensive trying to break all effort into small pieces. You’re customers are “allowed” to change their mind, so – what’s the point of understanding that something being requested for next year, will take 121 hours to develop? In 2 weeks, hell, in 2 days, this effort might cancelled. Breaking future effort to small pieces is great, but only if it’s extremely cheap to achieve or extremely relevant now. Until then, you might be okay with high level estimation.

The perfect size: big enough, small enough

Sprint should be big enough to (1) achieve meaningful progress and (2) avoid unacceptable overhead of planning + reflection. That means that if your smallest effort is always at least 1.5 weeks, don’t use 1 week sprint. If you need a full day to plan a sprint and another to reflect on how it went, don’t use 1 week sprint. Otherwise, your people might feel “we’re doing nothing but planning and reflecting”.

Sprint should also be small enough to allow to reflect and adjust often. Just like “release often” attitude, adjust often will make the organization work better, faster. Don’t dismiss it lightly.

How many sprints should I plan in details?

Good question if I may compliment myself for asking so. I would aim for detailed plan at least 1-1.5 months in advanced, unless you’re in a really volatile market and 1 month is “too far”. If your sprint size is 2 weeks, then I would say around 2-3 sprints. By saying “in details” I mean very detailed understanding of effort, real breakdown or very solid understanding, based on similar effort in the past or one-of-a-kind magic ball. The idea is to have good image of near future; this will obviously be expensive to create, but will give you confidence on how to achieve the most important goals on your table.

I would try to understand what’s coming later on (3-6 months), but invest much less time and stay with high level estimation. I don’t want to waste time on planning potentially irrelevant effort.

Natural dependencies planning

When sprint size picked wisely, there is much “smoother” feeling of dependencies planning. There is no real need for Gantt or something of that sort, thank God. Everyone will be aware of the effort being made in the sprint and will align dependencies accordingly. The feeling will be more natural, more just-in-time rather the stating “we need infrastructure team to finish in 6 months something so we could use it 9 months from now!”. It doesn’t mean that dependencies planning is gone out the window, you’ll still need to do so for big infrastructure effort, but you’ll see that it happens less than you were used to. This is a good thing.

Reflect and adjust

At the end of the sprint, it’s a great time to sit down and consider what went well, what wasn’t (take Action Items) and what can be done to have better sprint next time. You’ll adjust to external changes better when you’ll adjust to internal pains better.

I thought that Agile == no planning

Now, that is just sick. Seriously, no one is expecting you to work badly. Great planning is the only way to produce great products to your customers, deliver it on time and with high quality.

Not all planning are born equal

Accept it, plan accordingly :)