When planning an agile project creating User Stories and estimating their complexity is an important step to provide your customer and delivery team with a clear understanding of the solution being developed. Estimating the complexity of a User Story is something typically done by a Product Owner after or during a meeting with a customer then verified and approved by the delivery team during release and sprint planning. Make no mistake that this is a consensus not a majority rules estimation process. While the project owner gets first stab at story point estimation it is the delivery team that will be responsible for doing the actual implementation. The delivery team should never commit to adding a story to a sprint without first having a conversation about the delivery team tasks required to bring the story to the teams stated definition of done.
Since we are estimating relative levels of complexity and not actual hours a modified Fibonacci sequence can be used for estimations of User Stories received by the development team. This will help keep the team from getting bogged down looking for exact estimates and allow them to “round up” to the next level of complexity.
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100
Complexity vs Hourly Estimates
Humans are not very good and estimating actual time for complex activities. But we happen to be very good at estimating relative complexity, this will be about as about as hard to do as that was. So when estimating at a high level such as story points it is best to keep those estimates at the relative story point level and save the more precise detailed estimates to the delivery team tasks to be captured during release and sprint planning. Also whenever possible it is best to keep User Stories to a size that will fit within a single sprint, even better to keep them down to 1-3 day sized chunks.
Ultimately Delivery team tasks will be nested beneath the User Stories at a more granular level so we can save time estimates for these smaller work items. The sweet spot for tasks nested beneath User Stories 2 to 4 hour chunks. After 6-10 sprints and sprint planning meetings your teams story point estimations should be pretty accurate.
Since the teams capacity describes the amount of story points that the team can finish in a sprint and a sprint is a time boxed event if we accurately estimate the number of story points we can finish in a sprint we can extrapolate the number of hours required to complete the committed story points.
A great way to start the conversation about task estimates is to play Planning Poker. Here is a great video to get your started: https://youtu.be/MrIZMuvjTws
User Story Slicing
If our User Stories are too large to fit into a single sprint it may be an Epic or Feature masquerading as a User Story, in this case it is best to break this large complex User Story down into smaller chunks to make it easier to understand. We call this process slicing or sizing of the User Story. If we think of the User Story as a slice of double chocolate layered cake (the flavor was irrelevant but call it a craving) then we can think of our slicing efforts as a slice of cake from top to bottom and not simply peeling off the top layer (otherwise you miss out on the frosting between the layers).
Slicing the cake vertically means we follow our business process from the User Interface layer all the way through to any data access components that might be involved, in other words if we have a log in user story we can actually log in because the UI, data layer and database required by the story are all in place.
Small Increments
Let’s break things down into smaller components so that you can understand. The larger the size of the user story the more moving parts it has, the larger the margin for error. Also if the user story is too large to fit in a sprint it will affect the team’s apparent capacity and velocity as the burndown chart will not move until the story is marked as complete. A large user will have many delivery team tasks nested beneath it each of these tasks will have its own time estimates and since the sweet spot for these tasks is 2 hours a large user story could potentially have tens of tasks associated with it.
Story as a container for work items
The User Story is a high-level nontechnical customer requirement and is meant to ease communication between the customer, product owner and delivery team. As such the user story is not the place for technical detail, this is the realm of the delivery team task (formerly known as developer tasks). The story point complexity rating has a direct impact on the number and size of delivery team tasks to be expected for each user story. As a general rule it is best to keep tasks to small workable chunks created and assigned in 2 hour increments. Two-hour delivery team tasks make estimation far more precise by reducing the margin of hour to minutes instead of hours or days. During sprint planning we should strive to identify about 2/3rd of the required technical delivery team task as the effort and time required to identity 100% of technical delivery tasks. We should spend on average 2-4 hours in sprint planning for each week of the sprint.
The more complex the User Story the larger the delivery team tasks will be. The larger the delivery team task the less accurate the task time estimates will be. Put simply the more we reduce the amount and size of work in progress the more accurate our time and complexity estimates will be. See our post on Slicing User Stories for more detail on how to size or slice large and complex User Stories.
