Thursday, September 01, 2011

Sticking to Estimates

I got a great comment from Kelly Waters on my recent post "Scrum: No commitment required" via his web site. After responding I realized that the response was a good basis for this follow-up to my original post.

In the original version of Scrum, the commitment of the team for the sprint is dependent on two things: a good work ethic and good estimates. If either one is an issue, then the work won't be done on time. The “no commitment required” title of my previous post was a bit tongue in cheek. Absolutely commitment is important, but I don’t think that making it part of “Scrum” will suddenly make team members with a poor work ethic suddenly have a good work ethic or team members with problems estimating better at estimating. Nor will having commitment part of Scrum automatically improve a bad team/PO dynamic. 

People with a good work ethic will work hard. If you have folks with a poor work ethic, I believe Agile will expose this more clearly and then you can use your management skills to address it one way or another. Hopefully, with a win-win solution.

Estimates are just that, estimates. They are a good-faith representation of what the team believes it will take with the information they have at hand. When something is discovered, then it is important for the team to communicate that to the PO, but I don’t think it means that they have to stick to the original estimate. Is that “letting them off the hook?” I don’t think so. Let’s face it, if they estimate 8 hours, but it turns out to take 24, the only way to do it in 8 is to do 8 hours “on the books” and 16 hours off. To have the team absorb those extra 16 hours means that they will have to take it out of their own time which is violating the idea of sustainable pace.

If you have a team that consistently misses their estimates, that’s something different. Missing estimates should be the exception rather than the rule. When it becomes the rule, the question is what’s going on? Is team morale low? Why?

When using story points combined with tracking velocity, there shouldn't be a problem with estimates because story points and velocity should make the issue of estimates a moot point. What I mean is that if all estimates are suddenly off by a factor, the result is simply that velocity goes down. If estimates have always been "off" then velocity will not be going up or down, it will just be fairly constant. Since story points and velocity are relative, estimates that are "off" by a factor aren't a real problem.

Instead, the “problem” may be manifesting itself more as a general feeling of “this team just doesn’t seem to be as productive as it could be.” But then you are back to “why not?” I don’t think an enforced framework of commitment will change anything if the team has, for instance, low morale.

On the other hand, if the problem is wildly varying velocity (perhaps due to wildly varying accuracy of estimating stories) then I would venture there is a good chance that the stories are just too big in general and a good remedy to consider is to aggressively split stories into smaller stories.

5 comments:

Neil Craven said...

The only thing you learn from regularly missed estimates it that your team is bad at estimating. You can then investigate why - perhaps they are overconfident, perhaps they have too may interruptions. My experience is that they tend to miss how hard refactoring and regression testing is is because of poor functional/acceptance tests, possibly through poor coverage or because the build takes too long to give good feedback and reduce the burden of assumptions.
I'm currently trying an experiment where, as well as tracking estimates, I'm just looking at how long stories take to get to "done" on average. If our stories all follow the INVEST model, perhaps we can plan just on the number of stories, rather than size estimates. Estimating is painful, can take a lot of time and I have found that after a while, most of the team lose confidence in it.

Lisa said...

Thank you for pointing out that the Scrum "commitment" to N number of hours is not going to make the team work smarter or harder. We decided a couple years in to Scrum that it was silly for us to wear hair shirts because something happened and we didn't complete all the stories we planned. The problem wasn't lack of effort or brains on our part. It could have been lots of things: misunderstood story, unexpected production issues, power outage, whatever. So we quit wasting time on "committing".

The idea of planning 2 weeks' worth of stories is actually kind of silly too. We need enough work to keep busy for a few days, for sure, but we can always bring in more work when we're ready. We plan some "on deck" stories if we think we will need them, or just let the product owner know we may need more. We don't really pay attention to our velocity, but it actually went up when we stopped "committing" to two weeks' worth of work.

The down side to this was the biz folks started to think "we don't have to have all the stories for the sprint ready on Day 1", and they started slipping further behind in getting us enough requirements to start each story. It happened so slowly that by the time we realized it, we were wasting all kinds of time going back and forth trying to find out requirements. They need to have discipline too. So now we tell them that from their end, enough stories should be ready to go to keep us busy for 2 weeks, though we don't promise we will get to them all. Generally, we still run out of work and need more.

That is such good advice to make stories smaller. It took us a long time to learn that. Once we did, we were able to avoid unpleasant surprises and keep a steadier pace.

Sonam said...

Monetary backing that can help you meet short-term needs until next payday.with www.getpoundtillpayday.co.uk

Ethan Moore said...

Nice Article!! I agree to your view that making commitment part of “Scrum” will suddenly make team members with a poor work ethic suddenly have a good work ethic or team members with problems estimating better at estimating.When the team self-organizes and the project has attained constant velocity, the Scrum team will be competent to make, and meet sprint pledges based only on verified velocity and their estimates of Story Points. Some Scrum Masters may want to continue enabling this freedom as a good Scrum implementation.Here I would also like to take you through our article on https://www.scrumstudy.com/blog/better-task-estimation/

rinto ar said...

Grateful forr sharing this