Estimating stories quickly and efficiently with ‘The Rules’

An Old Timer by hiro008
ticktickticktickBING - An Old Timer by hiro008 on Flickr

Estimating a backlog should be easy, especially if your Product Owner has looked after it, knows how to write good stories that mean something to the developers and the business and is able to prioritize based on business value (or, customer delight!). However, estimation meetings, poker planning, planning two or whatever you call it, can often be painful events that descend into chaos, anarchy and heated debate. While these things are all fun, estimation should be fast and simple, afterall applying arbitrary numbers, whose only measure is relatively sized, to amorphous items of work can’t be rocket science, so why would you want to spend much time on it?

Trouble is, developers and engineers are paid to solve problems, that’s what they love to do, so they begin the moment the problem is presented! This is to be applauded, but doesn’t really nail what should be fast conversations about stories!

We’ve recently been coarse estimating the next releases’ worth of stories for each if our products, the backlogs for these products contain between eight and 38 stories, depending on the goal. When we started estimating these, it was clear that it was going to be painful, so I created ‘The Rules’ (to be clear, they’re guidelines, remember the Shu Ha Ri!):

  1. Reset the countdown timer to five minutes.
  2. Product Owner reads story and acceptance criteria.
  3. Team ask questions to clarify their understanding of the feature. No technical discussion.
  4. When no more questions, the team estimates.
  5. If estimates converge or there is consensus, GOTO 1 and start a new story.
  6. If no consensus, start more discussion. Technical discussion is OK here.
  7. When the conversation dries up, or the time ends, whichever is first, the team estimates again.
  8. If estimates converge or there is consensus, GOTO 1 and start a new story.
  9. If a consensus isn’t reached, reset the time for another five minutes.
  10. When the conversation dries up, or the time ends, whichever is first, the team estimates again.
  11. If a consensus still hasn’t been reached after 10 minutes, put a question mark next to the story and GOTO 1 and start a new story.
  12. Optionally: create a spike story to discover more information in order to estimate the difficult story.
This means that the team will never take more than 10minutes to estimate a story. Usually, I’ve found, that the first estimate, right after the PO reads the story and the team clarify their understanding, is enough and rarely do we need the time for the second timebox of five minutes.
Remember, these are just estimates, they can be revised later if necessary and, really, the important part of this meeting is the conversation to clarify the requirements and, thus, ensure that business value is met.
Advertisements

Estimate like you mean it

Scrum says that planning poker should be short, snappy, time boxed and fairly rough. The more ambiguous the stories, the higher the number on the Fibonacci scale. This is great, it allows you to discuss the story at some length, make sure you’re all on the same page and then throw up a number.

What if your team doesn’t understand every aspect of the project? If you’re new to scrum, or you’ve got silo’d ‘specialists’ for different segments of your product or company (and, honestly, who hasn’t?), or you’ve got a new team member, perhaps a new hire, or someone from another team altogether, then planning poker might not be the most productive hour of your week. You might need to spend time during planning discussing what the story is, how the section of the product or application works and why. That’s going to eat into your timebox for discussing the actual story. So, how do you get round the fact your team isn’t all fully aware of the entire application, or even, in some cases, the part of the application your team is assigned to?

You could just go for it anyway, you might get lucky and everyone estimates the same anyway, your velocity may change, perhaps, but it’d stabalise in the end. Or you could run some workshops to get the new team members or those unfamiliar up to speed with the product, but that eats into your sprint time.

Or, you could send out the story ahead of time and let the team members spend some time pondering it before poker. Email or print and drop on each persons desk a list of the stories (which should be well defined and adhere to the I.N.V.E.S.T acronym) and let the team spend some time getting a feel for them. Those that are most familiar with the project can scan through to see if there’s anything out of the ordinary and those less familiar can spend a little time asking other members of the team, or even getting acquainted with the code. Up close and personal like. That way, when you come to planning, your timeboxes could, if you wanted, be that much shorter and your estimating should be more accurate, making the entire process a bit more solid. As more accurate estimates lead to confidence in committing to stories, lead to delivering what was committed to, leads to sticking to a release plan, leads to the team being full of WINN!Of course, this does all assume that your stories are well defined…

Should you bother with a product backlog?

I recently started a conversation on the agile development group over at Yahoo Groups. My initial question was, should I ditch the product backlog? We tend to do a lot of just-in-time development, the requirements come in, sometimes mere hours before our sprint planning and as such, these stories are only on the product backlog for a very short period of time, if at all. Often they’ll just come in via email from the Technical Director and they get added to the sprint. The backlog, then, becomes ever growing and it seems that some of the stories on there will never be looked at again, let alone completed. It’s the fable of the ever-growing backlog.

So, do we even need it? Jack Milunksy of Agile Buddy fame said, if you’re not using it, then in pure lean fashion, ditch it and stick with the just in time. Others have said, if you’re not using a product backlog, how will you define a release strategy or be able to roadmap the product? Which is a good point. The answer then is that it depends. Why is this always the answer with anything scrum? 😉

If you’re using the product backlog as a place to store and prioritise stories, use as a release manager or roadmapper, then you should keep at it. If you’re using the product backlog as somewhere to store half-formed ideas of possible features of additions to your product, then maybe you should use a backlog. If you get your priorities minutes before the sprint starts, hastily written on the back of a beer mat, then maybe not. Or, maybe just use it to store high priority stories that are definitely going to be worked on but not yet.Above and beyond all this though, is grooming. If you don’t groom your product backlog, then you’re in a whole world of pain. Epics, which are at the bottom will suddenly become top priority and, without grooming, will still be Epics. Your team may even throw things at you, I wouldn’t be surprised. So groom the backlog regularly, get the team involved and make sure you’re breaking stuff down!

Update: Jack Milunksy over at the Agile Buddy blog even blogged about this: http://blog.agilebuddy.com/2009/11/do-you-even-need-a-product-backlog.html

Grooming a product backlog

How many times do you or your team work with the product owner to groom the backlog? Once or twice a sprint? Once a month? Less? How about trying to do it every other day, or even every day?

Grooming the product backlog is one of the most important things you can do in scrum (besides following the rules and um, delivering). It helps you maintain a healthy outlook on what you’ve got to do, it helps you recognise and deal with dependencies and blockers earlier and it goes a long way toward release planning and estimating a project delivery date (or date range, more likely).

Also, if you groom the backlog daily, it’ll take much less time and be a much less arduous task. I’ve done both. Sitting with the product owner once a week to groom a backlog of many, many stories is a pain in the arse. The most appropriate time is just after the stand-up. You’re all standing around the sprint/product backlog, so take the time to ask for a couple of volunteers to spend 15 minutes examining some stories, grab the product owner as well. I always suggest that anything bigger than a five pointer is probably a good candidate for breaking down a bit further or defining acceptance criteria and anything bigger than a 13 should definitely be broken down further.

Take a big or ill-defined story and ask, can this be broken down? Can we break this into any smaller parts that offer business value? If so, then great, break it up there and then, if not, then ask if it can be broken into smaller parts that don’t provide business value? Sometimes, this is a worthwhile questions as, when you break a story into smaller, non-valuable parts, inherent value sometimes bubbles to the surface, taken out of context, the team might spot a way that smaller stories that don’t deliver value, might actually do so after all.

Then ask the team if the acceptance criteria is accurate enough, does it, in their opinion, describe the “done” state of the story? Obviously, the only party who can actually say when it’s really “done done” is the business, but your team will always have a good idea of what “done” is to them and the product owner should be able to offer more information on what the “done” state is.

Finally, see if you can ascertain some kind of rough priority order, this is especially relevant for technical stories that may not provide value for the business at large, but will often support other stories that do provide value and you should always try and pay off your technical debt wherever possible.

So, if you groom the backlog with the product owner and various members of your team more regularly than you do now, when you get to sprint planning, it’ll be a breeze. You’ll spend much less time discussing what the stories mean than the actual tasks needed to complete them. You’ll know exactly which supporting technical stories you may need and, if you’ve been aggressive at breaking down stories to two, three of five story points, you’ll be able to be fairly accurate with your commitment.

And really, that’s what it’s all about, being slightly more accurate, so the confidence of your team is high that you can complete what you’ve committed too. Your team will love you for making sprint planning less like pulling teeth and your product owner will love you for delivering what you’ve committed to.

Win-Win as they say.

Guessing a velocity

You’re at sprint zero. You’ve got a new team. You’re new to scrum. You’ve never quite managed to stick to the Scrum framework. All reasons why you might not have a velocity. I’m sure there are more, but these are the most common. What do you do? How do you know how much you’re going to be able to fit into a sprint?

You guess.

Yes, I’m serious. If you’ve groomed your product backlog for the first sprint, estimated your stories and refined those estimates and broken down larger stories, then the only thing left to do is guess. Gather your team around and ask them “What do you think you can fit into this sprint?”. Once the team has picked from the highest priority stories and agreed that they think they can fit the work in, ask for their commitment. It’s at this point that you’ll need to help the team decide whether or not they’ve over committed. Most teams almost always start out thinking they can deliver more than they really have the capacity for. It’s not because they’re showing off, or because of any kind of arrogance, they actually do think they can deliver what they’ve said they will. Remind them that, while the stories are well written and the acceptance criteria well defined, they are just the start of a conversation with the business and things could change.

Your team will probably decide to knock of one or two stories and right now, that’s fine as they can always go back into the sprint if you find yourself running out of stories half way through. Once there’s a commitment, add up the story points. That’s your predicted velocity. It may not be accurate and it’s quite probably wrong, but right now, right this very minute it’s the most accurate idea you have of how much you can deliver in your sprint.

Why is this useful? Well, it will give your team a target, they’ll want to actually hit that velocity prediction as they’ve said they would. It’ll also come in useful for release planning and having some kind of vague idea of when your product might be delivered. You know least about how long or how complex a task is right before you start it, but now you’ve got some benchmark. You can add up the rest of the story points on your backlog, divide by the predicted velocity and have a figure which is roughly how many sprints you’ll need before you have delivered your product.

That is something that the product owner will shit himself with excitement about. Assuming he hasn’t asked you to translate that into a gantt chart.