Tuesday, November 25, 2008

Flexible scope - A magic bullet?

Everyone agrees that you can’t both have a rigid deadline and a rigid scope. We’ve been there, Done that, Got the g***amn t-shirt. Software Development is not mass production and last time I checked I wasn’t able to foretell the future. We want to avoid projects where both the scope and the date are fixed. That’s one of the first lessons every developer learns… And that is one of the key things that Scrum brings: you develop in iterations, you timebox and you ensure you have something to deliver all the time, especially release day. Yay!

Timeboxing means the date should be regarded as fixed. Wow, there’s an easy sell to upper management…! But as a consequence we
have to allow the scope to flex… Simple enough? Well, allowing the scope to flex might not be as easy as it seems. “Flexible scope” as a concept is easy enough to understand, but it’s not something that happens by itself just because you say “we do Scrum”, develop in iterations with beautiful sprint planning sessions and sprint reviews.

I’ll illustrate with a scenario that I’ve seen in reality several times:

Let’s say you’ve started using Scrum, and one of the key selling points to upper management was: “In Scrum we never move the deadline, we promise to try to always have something releasable at the deadline. I can’t promise exactly what, but we won’t ever need to move the date”. Good start!

So, now you start working. The team is working on a release of (let’s say) two major features (each consisting of several smaller “parts”). The Scrum Product Owner and others work on breaking down the scope(s) into User Stories. But they’re not really familiar with Scrum and the stories they produce are poorly formulated, and are done without them really understanding what a User Story is and what to think of.

Still, eventually a product backlog is ready. But, again since the Scrum Product Owner might not be that familiar with Scrum there is not much effort or thought put into the prioritizations of the stories in the backlog. Anyway, the team starts their sprint with a sprint planning meeting and grabs whatever is on top of the backlog.

Once rolling, the team execute the sprint with little or no regard to the priorities. Everyone grabs a story each and start working.

Work continues along those same lines sprint after sprint. And stuff actually do get done. Progress is OK, people feel OK. So far so good?

Now, when you approach the intended release date, you look closer into what’s been done so far and you conclude that there are still several critical things that aren’t ready yet, or that maybe haven’t even been started yet. In addition, you conclude that there are critical tasks remaining for each of those stories which you previously thought were “Done” – tasks such as integration testing, string translation, code reviewing or similar. Ouch.

At this point, what are your options?
  1. The "easy" way out is to postpone the release date, i.e. effectively breaking the timebox rule. …Scrum breaking down. Oh misery…! And you had such an easy sell to upper management with the fixed-date thing... And all you do is move the date and then have the same problems once more, but that time you've sortof used up your goodwill and no longer have the luxury (?) of being able to postpone the date...
  2. Crunch! There's that word again... But you think "Just this time… This release was special...". You make up excuses about why you’re where you are, and call for overtime. Have people come in a little earlier and stay a little later. Have them come in those last few weekends. Not to mention those last days before deadline. So, the team works overtime, they put in extra hours, and not surprisingly quality suffers, people suffer, shortcuts are taken everywhere… Anyone recognize this?
  3. Flex the scope by lifting out the entire feature from the release. Since there are still critical stuff remaining you don’t have the option to just abandon parts. All you can do is lift out the whole feature. That doesn’t give such a good impression of the whole “flexible scope” mechanism, now does it? “Yeah well, in Scrum we don’t move the date, so we have to let the scope change, and that means removing a feature from the release. We have to allow that. That’s Scrum.”. A job well done. No, this is not what “flexible scope” means.
Those are really the only three options. And what’s even worse is that this is probably not discovered until very late. With only days or a few weeks (best case?) remaining until the scheduled release date… This is Scrum failing big-time!

So, the point I want to make here is that we need to be very careful so that we really maximize scope flexibility. The main mechanisms in Scrum which are affecting this are:
  1. Strict prioritization
  2. Ability of adhering to Definition of Done == Releasable.
  3. Skillfulness of breaking down a scope into user stories
To me “strict” means that we both prioritize AND stick to it, by actually working on things in priority order. If we don’t have a prioritization we can’t really say that we have done all in our power to have everything “critical” or “most important” (or whatever value you want to put in the prio) ready by the time the timebox ends. If you’re not careful, the “completed” part of the scope may be any combination of important and less important things, and (what’s worse) the same is true for the stuff that isn’t done yet.

Prioritizing the backlog needs to be intelligently done, and only 1 person should be allowed to have the final decision about a story’s priority: the Scrum Product Owner. I recommend thinking of the importance in terms of “Business Value”. But be careful; it doesn’t only mean value as in dollars and cents (or Swedish Krona and Öre ;-)). The keyword here is Business. Think of it in terms as Value to your Business, including your own internal business of developing stuff. So things that for example are “
architecturally significant” (I’ll post an article separately about this topic, some day) might get a high Business Value because it is important for the architecture and the consecutive development of other stories - even though the story itself may have less of an obvious value to the end user, the customer, your accounting department or your shareholders (but remember: if it is architecturally significant it is most likely valueable to the customer and end user too, it's probably just a matter of thinking about it hard enough and being able of formulating it in words).

The Definition of Done applies to how you “complete” stories. I’ve posted entries here in the past about this and I won’t go into details here. I just want to point out that adhering to the Definition of Done affects your ability of flexing the scope, because you ensure that you stay in control over what’s remaining; you stay on top. The things that have been done are really “done” and are really releasable, there are no hidden piles of work under the rug. I hate surprises and Definition of Done is my best friend :-).

A largely contributing factor both to your ability of adhering to the Definition of Done, and to your ability of following a prioritization, is how good you are at breaking the scope down into User Stories. Don’t regard the scope as a big monolithic lump of functions (e.g. the waterfallish term “Requirements”). Instead, you need the stories to be independent, finishable, valuable and estimatable. A good guide on the way of thinking you want to have is the I.N.V.E.S.T. acronym (stories should be Independent, Negotiable, Valuable, Estimatable, Small and Testable). Writing stories is a skill that you have to work actively with and continuously try and improve.
Don’t be alarmed though; it’s not rocket science. Some breakdown is better than none, and you shouldn’t make such a big deal out of it. Learn by doing. Try different approaches to formulating stories, try the INVEST acronym, try other ways. As long as you understand that the “quality of the breakdown” will affect a lot.

So, to wrap things up: with intelligent scope breakdowns, by following the prioritization and the Definition of Done, we can be more than reasonably sure that the e.g. 85% of the scope which is “ready” when the timebox ends, is really ready, and the remaining 15% is not half-started and we don’t have dependencies between the ready 85% and the remaining 15%. We know we can release
something – and that something is actually something valuable (hopefully even the maximum value).

There. Long post this time. But I like this subject. And it's an important one. I’d be glad to learn about other peoples’ experiences. Cheers! My food is getting cold.... ;-)

Wednesday, November 19, 2008

Have you ever looked at a burndown, really?

The topic today is about burndown charts. I’d like to make some remarks about what it is used for and why we have it.

First of all, the Burndown Chart is a pretty obvious artifact of Scrum. If you use a wall or whiteboard as your “Scrum Board”, you probably have the burndown close-by and you probably (you should) update it daily. As with most artifacts and mechanisms of Scrum, the basics of the burndown chart is pretty easy to understand. So, at a glance, the burndown chart is self-explanatory.

But is it?

Introduction to Burndown Charts
Let’s start out with discussing what the burndown chart is, mathematically/practically; The burndown is the sum of remaining time for all those items in the sprint backlog, spread out over time along the sprint. So along the X-axis you have your timeline, typically measured in calendar days (at least work-days). Along the Y-axis you have remaining time. You can measure that in Days, in Hours, in Gunships or whatever you want. I recommend that you measure it in (people-)days, though. So, on the daily scrum (the standup meeting) the team goes through all the items in the sprint backlog and they figure out the current remaining time (e.g. by summing up all tasks, or whatever level of detail you have on your scrum board). The sum is plotted in the burndown chart. The result is a plotted line that (hopefully) moves from the top left corner, to the lower right corner. By observing this line the team and everyone else can clearly see how well “on track” the team is: will we reach 0 by the time the sprint is ended?

Can the burndown be "ugly"?
Another important remark (that maybe and unfortunately isn't so obvious) is that the burndown chart is intended as a tool for spotting problems early (by displaying progress daily), which means that it has to be reliable: it has to be the real progress, the hard cold truth - not some made-up half-truthful data that makes the chart "look good". Ever thought of a burndown as "ugly"? I know I have. Sorry, but it is not the burnchart that is ugly (don't kill the messenger): it's the reality. It's the context in which the sprint is executed that is "ugly". As soon as you start "dressing up" the burndown you start hiding the truth. And who will end up biting the dirt for it in the end? Yes, the team...

So, a precondition for having any use what so ever of the burndown chart is that it is as truthful as it is current/up-to-date.

A deeper use of Burndown Charts
But why do you do this at all, track progress and plot it in a burndown? Why display it in this way? Or more specifically: what do you (you, the team, the scrum master, everyone) do with this information?

I know for my own part that I’ve observed hundreds of burndowns by now, and so have all of my colleagues. But I’m not sure that everyone has really spent time reflecting over what the burndown charts mean, other than the immediate, most obvious: that we can see if we have more work remaining than what will be reasonable to finish by the end of the sprint. So, that’s why I wanted to bring this topic up: to get a chance to reflect over how to use the burndown in a deeper, more analytical way: more effectively.

Also, I think most people just reflect over the single, immediate burndown infront of them, without specifically observing or thinking about the burndown in the context of other burndowns from past sprints.

The burndown, in combination with the Scrum Board is an excellent and powerful tool that tells a lot about the immediate climate and environment of the team and the ongoing sprint. If you have knowledge about burndowns and velocity of past sprints, then you have even more powerful information. The burndown – and a set of several burndowns from past sprints – is like a flashlight revealing problems. As soon as there is a problem with progress it is shown in the burndown. But equally important: if you have problems with planning, with product backlog maintenance, with outside disturbance or even with your Scrum implementation as a whole, it will show in those burndowns – if you just know what to look for, and if you realize that this is possible.

So, I guess my advice is: take time and reflect not only over the current burndown, but also reflect over the last 2-3-7-whatever sprints and their burndown, at the same time. I suggest you take a photo of the sprint burndown chart at the end of each sprint and archive it together with records of the estimated and the actual velocity. Then bring that out now and then, let the team get their hands on it and spur discussions about how it looks. Discuss patterns and findings.

Scenarios to reflect over
Below are a couple of made-up burndown charts that I made in Visio (yay!) to visualize some key points. I intended them to represent two consecutive sprints each.

Two sprints showing an interesting tendency...

What would it mean if you see a pattern like above? Here, already from the first few days of each sprint, it is possible to see where the burndown is headed. It is however left like that for too long time, but at least the team acts at some points, by (probably) removing stories from the sprint. So that’s good. But the next sprint shows the same tendency. What if this happens a third time, and a forth? It is clear that the team is over-committing every sprint. I.e. they are not following their actual velocity carefully enough. They are ignoring reality (velocity) and convincing themselves that “next sprint it will be different” – but it never is. So, by observing the burndown over a few sprints you can see that (1) the team acts by removing stories (great), but (2) the team keeps over-committing. It is shown in the burndown as well as in the actual compared to estimated velocity.

Two sprints that show flatlines...

What about the pattern above? Well, the team is unable to complete items – for some reason. It is not resolved (or new problems with the same result keeps appearing) over several sprints. So, the obvious issue here is that the impediment perseveres and renders the team unable to finish items. The not-so-obvious problem here is that nobody seems to act to resolve it. Two sprints is a long time. Remember that Scrum says that impediments should (optimally)be removed in a day. So you really have to issues here that you need to resolve: (1) fix the impediment stopping the team from finishing items, and (2) find out if and why nobody is addressing that impediment.

The two examples above are easy ones, but still I’ve seen them both. I think a lot can be saved by observing both the current burndown and really reflecting over it, but also (not least) by now and then observing the burndown of several sprints in a row.