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.

The Definition of Ready

Well, I’ve only gone and got myself published on the Agile Journal! Here is what I had to say:—–

Ready 4
Are you ready? Image by Kevin Dooley on Flickr

Development teams use the idea of a definition of done (DoD) to decide when they think a user story is ready to be shown to the stakeholder for review. The DoD is like a bouncer or doorman, ticking technical criteria off on a list before the story is allowed in to party. The DoD is a powerful tool, and while its explicit value is obvious in ensuring the quality of a user story before review, its implicit value is equally, if not more, important. The DoD forms a contract between the development team and the product owner (PO). This contract not only ensures that stories meet a baseline of quality but it also creates a bond of trust. The PO knows that, with a DoD, he can trust the team to deliver a quality technical solution, and in agile software development, trust is key to your success. The acceptance criteria form a similar bond between the PO and the stakeholder or business. The criteria are designed to help a PO decide if a story meets the stakeholder’s requirements. It’s this list—defined in conjunction with the stakeholder—that creates trust on the stakeholder’s side. They know that their PO will deliver what they need, because it says so on the story. The DoD and the acceptance criteria combine to make a powerful ally for your team’s success. But both of these things require that the user story itself is sensibly written and defined and that the acceptance criteria aren’t some magical pie-in-the-sky, moon-on-a-stick list of ridiculous demands that would give a hostage negotiator nightmares! The PO can make use of a similar DoD called the definition of ready (DoR). This can be used for all the same reasons the DoD is used for the team. It’s useful if the Scrum team helps the PO come up with a DoR, help her define things about stories that make them easy to understand:

  • small enough to be manageable in a sprint
  • contain enough detail to estimate accurately and
  • create acceptance criteria that really help define “done.”

POs don’t just pluck an idea out of the air, write a user story, and drop it onto the backlog (we hope). Stories go through a process just like the software they drive does. The PO has a responsibility to the team to create user stories for them to estimate and, at some stage, work on, that aren’t badly defined or not thought through. Team members don’t want to have to do a bunch of the PO’s work in order for them do their own work and deliver value. To this end, a PO and the Scrum team might find the DoR useful. This is a contract that the PO has with the team in order to say “Before I put a story in front of you, I will have done everything I can do make it not suck.” Some examples of criteria on a DoR are:

  • Story contains actors, problem, and value
  • Story should fit in a sprint
  • Story should be appropriately documented (does it require wireframes? User-journeys?)
  • Value should be obvious, if not, it should be explicitly stated
  • Story should have reasonable conditions of satisfaction
  • Story should focus on problems, not solutions

Using the above example, we could ensure that the user story: Show users other products that they can buy before they checkout which begins life as a throwaway request from a stakeholder at an audio-visual online storecan be rewritten using the DoR as: As a customer, I would like to see products that I might like to buy at the same time as my television, hi-fi, or other product, so that I can be certain I have everything I need. Acceptance Criteria:

  • Show users products that other customers, purchasing the same products as this user has chosen, have bought also
  • Based on what the user has added to his basket, show him products that could potentially be used with it, e.g., if he has chosen a TV, then show him cables, TV stands, and Blu-Ray players
  • Show ratings and percentage of customers who ended up adding the additional products to their basket.

This shows the actor, problem, and value for the customer. The value for the business is implicit in that it will increase uplift. The story is appropriately documented with reasonable acceptance criteria, however it doesn’t tell the developers how it should be done technically. I’m a big fan of release planning meetings. These meetings include going over the team’s DoD to see if there are any changes team members want to make in conjunction with the PO or stakeholders before they start sprinting. This is an ideal time to create your DoR as well. In addition to the explicit value you get from having a contract between the Scrum team and the PO, the DoR also goes a long way to fostering trust (as long as the PO follows through) in the same way that the DoD and the acceptance criteria do. If you have a bad sprint, during the retrospective, you can review your DoD and your DoR. Did the story require more work before it went into the sprint backlog? The DoR provides a similar yardstick to that of the DoD when looking for root causes of failure. Try adding a DoR to your process, especially if you’re having trouble with your stories being difficult to estimate or work on. You’ll reap benefits immediately, building trust and creating stories that have real value.

How do I estimate how long an agile project will take, before we start?

Elephant Black and White

I was asked this a while ago and I’ve seen it mentioned a few times on blogs and forums and what not. I’ve answered it on a few occasions, so I thought I’d put it all into a coherent blog post.

Estimating a project before you start, with a brand new team is a tricky situation and one lots of people encounter.

There is a way you can work it out though, but your product manager should understand that it’s an estimate and it will change. If you need some backup, read this article on the ‘Cone of Uncertainty’ by Jeff Atwood and remember, you know the LEAST about a project right at the beginning!

How can I estimate?

There’s two ways you can do this; based on points or based on hours. I’d suggest using the hours method as it will give you a range. You can get a range with points as well, but only when you’ve done a few sprints. Some people are against estimating in hours and, usually, I am too. But for this “beginning of a project with a new team” exercise, it’s invaluable. The below all assumes that you have a product backlog ordered by priority.

I’ll start with the points method (and, step 1!):

  1. Estimate, in story points, your entire backlog. This is easier than you think and is often called the white elephant method, we use it with great success.
    1. Draw up somewhere a grid with 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ? as labels.
    2. Print out all your stories, or, if you’re already using index cards, just put them in a pile (but remember to put their priority order on them, so you don’t forget!) and put them in a stack somewhere.
    3. Now, each member of the team gets up, picks a story from the pile and sticks it to the board where they think it goes. If they have NO idea, then they put it in the ? box.
    4. Get everyone in the team to take turns in doing this. They must all do it in silence. Each turn they can pick up a story and place it on a board, they can also move a story that is already on the board, but they have to pick it up, face the team and say ‘I am moving this story because… ‘, then they can re-place it on the board.
    5. This goes on until all the stories are gone from the pile and no one is moving stories anymore.
    6. If you get two people moving a story back and forth because of a personal belief on it’s size, just have them put it in the larger number.
  2. Now, pick the story at the top of the backlog and say “Can we do this in two weeks?” If the team says yes, put it on the board, this board represents your sprint. Pick the next story and say “Can we also fit this story into two weeks?” if yes, put it on the board. Continue until your sprint is full.

Now, assuming you’ve story pointed all your backlog and the total is 260 points, you’ve worked out you can do 20 points per sprint, that means it’ll take you 13 sprints based on story points (so, 26 weeks). This will be quite wrong, but will give you a rough idea. If your product manager is bit simple, he might start telling everyone it’ll be done in 26 weeks. So, do the next step too:

  1. Ask each member of the team to estimate a max and min number of hours a day that they can work (taking into account meetings, phonecalls, emails etc etc that take time out of your productive, development hours); so Steve might say 4 – 5, Tina 5 – 6 and Hardeep 6 – 7. Work this out as hours per sprint. (So, Steve can do 40-60 hours per sprint in a two week sprint), with the above figures you’ll have a range of 150-180 hours a week;
  2. Remove all the cards from the board and put them back on the backlog;
  3. Pick the top story again, say “Can we fit this into a sprint?” If the team says yes, put it on the board again;
  4. Next, break this story down into tasks and estimate those tasks in hours;
  5. Do steps 3 and 4 until the team says they can’t fit anymore in the sprint based on the total number of hours (by adding up all the tasks) and their estimated man hours per sprint (ie: 150-180 hours per week as above), as a guideline, you should probably stop at around the 165 hour mark or, if the team cannot agree whether a story would fit or not, assume it won’t;
  6. Add up the number of hours they estimated, now you have how many hours they can fit into a sprint;
  7. Add up the story points for the sprint, this gives you your velocity.

So, you now do:

> total story points / velocity (from step1) =  number of sprints based on velocity (don’t use this though, it’s a very rough guide)
> number of sprints based on velocity x (estimated hours for sprint (from step 2)) = total hours for project.

and then:

> (total hours for project) / (lower weekly hours estimate) = minimum number of sprints
> (total hours for project) / (upper weekly hours estimate) = maximum number or sprints

As an example:

> 400 / 20 = 20
> 20 x 165 = 3300
> 3300 / 150 = 22 sprints
> 3300/ 180 = 18 sprints

So, now you can say to your product manager, the project will take between 44 and 36 weeks (assuming two week sprints). Again, this is still only an estimate, but it gives you a better idea. Especially as you know the least right at the start. The best thing to do is provide continual updates to the PM. Once you’ve done a couple of sprints, you’ll have a better idea of your velocity and you should groom your backlog frequently (including re-estimating occasionally) to keep your estimated delivery fresh, based on the most up-to-date knowledge.

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:

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.