We Don't Estimate Hours!

Now that I'm at Pathfinder, many new clients are coming in through the UX door and they are not familiar with Agile. I often have to explain how estimating and story points work.

If you search the Internet, there are tons of links about Agile estimating and story points so it seems redundant to add another but I really wanted to blog about this, if only to organize my favorite references.

So here are four links that cover just about everything on the subject (plus they'll send you to other places anyway). And if you don't have the patience to comb through these references, I've added my basic explanation to customers at the end.

1.I know Anand Vishwanath from a long time ago.  I value his overview for the thorough job it does of covering all the angles: http://bit.ly/MdH1tS

2. I love Dan North's post because it correctly, and effectively, shoots down that compulsive estimation marathon most companies want to indulge in: http://bit.ly/J9DvxF

3. Jay Fields is another former Thoughtworker who sums up the how-tos concisely: http://bit.ly/LbKy9Q

4. Mike Cohn is the ultimate writer in this area and this link leads to a chapter from his book on Agile estimation and planning, "Chapter 6: Techniques for Estimating": http://bit.ly/K6pvqQ

What I tell customers: We estimate expected effort, not hours. My teams count effort in points -- one is small, two is something more than small, three is something more than a one and a two, five is a large effort and going above five indicates the story is stated too broadly or contains enough unknowns to be manageable within an iteration.

Effort is either a measure of complexity (figuring out the unknown) or time spent on something that is naturally slow and tedious or a combination. Effort doesn't translate directly into hours but a team can use effort to figure out approximately how much can get done per iteration. It takes a team several iterations (2-5) to get a handle on their velocity (stories points completed per iteration) but you can use yesterday's weather to get a starting range for estimating a project.

Yesterday's weather comes from looking at what a similar team (size, experience) accomplished in a similar situation (familiarity with technology and domain). You only need one previous project to get this information. Use the averages - mean, mode, median - to figure out a likely range of outcomes and prioritize stories accordingly. Add 1-4 iterations for ramp-up (because both sides have to get up to speed) and 2-4 weeks for wrap-up (bugs, testing, and the unforeseen). Review and adjust the plan as you complete each iteration.

Is there room for UCD in Agile? part 3

So now we are at Question 3:

Do the UI stories count as "done", even when no software has been written?


"Count" is the operative word here. Do we mean "count" as in "keep track" or "tick off on a list" or do we mean "count" as in adding up some numbers and coming to a conclusion about actuals vs. estimates?

The purpose of saying a story is Done, is to have a means of measuring the team's velocity -- how much working software gets built on average per iteration/ sprint. Thus, in theory, you only really care about Done if the story is a coding story.

But you still need some way of determining if the flow of stories out of the backlog will impede the team's velocity. Now we're talking lean. Are stories getting delivered into the "ready-to-build" backlog fast enough so that the development team can always pull something off the backlog given their average velocity? Or are the developers going to sit around with nothing to do because stories won't be ready? Or better yet, can we move on to the next phase early because we're going to blow through / complete all the stories originally planned for this sprint/phase?

It is important to see the status of those higher-level analysis and UI research tasks that precede the coding stories. If UI work was substantial enough to make it visible as a "story" then you have to be able to say if it is not started, in-progress, or done, and have target expected completion dates so the team can get some kind of assurance about how and when the backlog may grow or shrink.

You can even assign and track analysis estimates and velocity in the same way that you track development velocity. But don't mix the two things together; the velocities are measuring completely different things.

UI research and the subsequent problem definition and solution finding (design thinking) will either add new coding stories, provide details for existing stories, or remove stories. Where the research provides new details for existing stories, that information will increase or decrease the stories's complexity. Likewise, adding and removing stories changes the estimated amount of effort in the backlog.

Being able to see when UI findings are likely to conclude gives the team information about future events that could affect the backlog and helps everyone roadmap the project's progress.

The team needs to be able to see it like this: Our velocity is V. The total point value of our backlog is 4xV so the project should complete in 4 sprints BUT, we still have two UI research tasks to complete and our experience so far on this project indicates that those tasks could add as much as 1xV each in changes to the backlog. So we have a total potential story point increase of 2xV. Therefore, as of today, our best estimate of finishing is in 5 sprints but we may need as many as 6.

(If you are curious about assigning story points for tracking velocity, here's one nice way to do it.)