At 18F, we believe that employing agile practices is the most effective way to build digital services. User story estimation is one of the most useful agile tools, and in this post, I’ll talk about how and why my team has been using it.
What is user story estimation?
A user story is a description of value to be delivered to a user, and an estimate is an educated guess as to how much effort it will take for a team to deliver that value. Our team uses a Fibonacci point system to estimate the size of that effort. The values are 1, 2, 3 or 5, with 1 representing the smallest chunk of work, and 2, 3 and 5 representing multiples of that smallest unit (why is the 4 missing?).
A 1 may be a user story where effort is really well understood, like “So that this user can navigate back to a homepage, a breadcrumb link to the homepage should be added.” A 5 might be something that is not as clear, but the effort is still somewhat understood. For example, “So that team member details can be updated automatically, they should be pulled in via an API (that already exists).” There will be more work involved with the 5 point story, and because of that there are more unknowns (even though the API exists, integration will likely involve some stops and starts).
Why my team uses it
It’s nice to point people to a pretty chart that shows how much work we get through every week, based on our estimations, so that they can track our productivity. But, we find that estimation is useful mainly because it forces us to break down large user stories into smaller, more understandable chunks that we can grapple with. Doing this regularly helps us:
- Focus us on delivering small increments of value that we can demonstrate to users
- Identify and deal with unknowns that are blocking the team
- Helps us prioritize as a team
Delivering small increments of value gives the team a sense of accomplishment and makes it possible to get feedback from users more quickly, which then allows us to iterate in the right direction.
I work on a team at 18F responsible for content and information platforms. The majority of the team came together after the initial codebase was written, so when we first started working together, it was hard to guess how much effort it would take us to complete a given user story. We’re still frequently off base, but the act of estimating has helped us identify unknowns, so that we can slowly reduce their effect through automated testing and documentation. Recently, we realized that our estimates around our API work were frequently way off base. This forced us to prioritize refactoring — or rewriting — the code, testing, and beefing up our documentation. This will slow feature progress in the short term but will make us move faster in the long term.
Although our estimations will never be 100 percent accurate, we already feel that our knowledge level around the codebase is improving, and the unknowns are becoming less of an issue. And we’re documenting everything so that we, and any new team members, will have an easier time getting up to speed. And developing a shared understanding of how to estimate stories over time will help us prioritize (small stories with high value get prioritized over larger stories that aren’t as valuable).
The end game of a product is to deliver and measure incremental value for users. The exercise of estimation helps us get there and keeps us going.