One of the great questions in software development revolves around “Is it done yet?” And since the answer is usually “No” the follow on question gets asked, “Well, when will it be done?”
I recently chatted with a ScrumMaster looking for estimating training for his teams. The teams work on a 4 week sprint cycle. I don’t have all the details, but it seems the teams have problems estimating how much work they’ll get done in a sprint.
The following could be wrong, but in my experience estimating problems result when:
- The sprint takes an extended work period. It’s more difficult to estimate how much effort fits in 4 weeks compared to estimating how much fits in 2 weeks.
- Lack of experience estimating. This gets compounded by managers wanting “accurate estimates.”
- Problems with user stories being too large and / or horizontal functions instead of thin vertical feature slices.
To help teams estimate better:
- Shorten the sprint length. Going from 4 weeks to 2 weeks makes the sprint end easier to keep in focus AND doubles the amount of practice the team gets estimating.
- Remember that an estimate is only that and nothing more. An estimate. And the estimates should get better with time.
- If there are problems with the user stories, work with product owners to write stories that conform to the INVEST pattern.
Do you have a question you’d like to ask? Shoot me an email.