Time's Up! How to use Story Points Effectively
For Agile product managers, story points are an essential part of the job. During each sprint, the product team works with other teams to set a sprint backlog of items to work on next. In some scenarios, this is easy, but in many others, market pressures, client demands and leadership expectations can conflict and introduce chaos. Nothing calms the storm of uncertainty and chaos like Agile product management processes. Using story points to estimate work to be done, during and outside of backlog refinement meetings, is key to planning and forecasting your team’s value output. That being said, there are many ways to do story points wrong, and one in particular that companies have a hard time with is quoting based on relative effort and complexity not time. That’s the dilemma we’re going to explore further today.
What’s a Story Point?
Alright, let's lay the foundation of this topic here first. Story points are units of measure expressing an estimate of the effort required to complete some increment of work. Story points are assigned based on a combination of complexity, risk, uncertainty and overall effort that it will take the team. Story points should not be based on time. Using points in this way, a product team can prioritize, plan, predict and adapt to changing product pressures. It also establishes a solid metric for tracking team predictability and productivity.
Why are time estimates not ideal?
There is a certain level of “abstractness” that has to be embraced and accounted for in all things product management especially when planning and forecasting timelines and project durations. When companies, instead, assign hours or “fixed duration” estimates, they create a clear window of time during which the work should or must be completed. This does not account for learning as work is done and for the real-life variables that can change the amount of time spent on any one item. In short, they aren’t accurate enough.
Using time-based methods of estimation can create product and development pressure to meet unrealistic deadlines and complete work underestimated timelines. This inevitably compounds into missing deadlines which leads to over-quoting tickets “to be safe” followed by reduced transparency and ultimately reduced psychological safety. When your teams don’t have a way to accurately quote and plan work, you’re wasting time and money each week. Story points give you a metric that can be abstract enough to flex around day to day issues and allow teams to give an estimate of “3” instead of saying this particular issue will only take 3 hours.
I mentioned it already, but it’s worth reiterating. Time-based estimates don’t allow the team to learn while completing the work. They don’t allow time for context shifting, meetings, research and more importantly unknown unknowns in complex work. We’re not fortune tellers in product management. As much as it may seem like we can “plan” our time estimates to perfection, it’s not possible; there’s a human element always at play. That’s the abstractness that story points allow for while bringing team productivity, predictability and improvement to the surface. Time-based estimates are not adaptable enough for modern Agile product management.
Relative Effort and Complexity
The best method to use for story point assignments is the Fibonacci Sequence (1, 2, 3, 5, 8, 13). This allows the team to estimate the level of effort and complexity abstractly with a clear understanding of the weight of the estimates. Each number is exponentially greater than the one before it. In this way, stories to be completed in the next sprint can be given a rating that everyone understands. This allows for working agreements to be established like “always slice 8 and 13-point stories if possible into smaller stories” which is one I implement for teams.
The best way to assign these story points is during backlog refinement or another call. Each member of the team should submit the number of story points they think the item deserves. Some tools allow a game of “planning poker” to be played where each teammate plays a card or selects a rating. When this is done, it promotes a thorough understanding of the work to be done across the team. Each member needs to understand the story to accurately guess at the relative effort and complexity.
When story point estimates differ, it’s time to talk it out. Members of the team that quoted higher or lower should discuss their perspectives and agree with the group on the level of effort. This allows a more senior dev to assist the group and it makes sure every issue is exposed to the full dev team. This is great as more minds mean more innovation. The process can also help to open up the dev team and conversations around the product more by providing a framework.
The best way to start and continue to calibrate team estimates is by choosing a few guiding light tickets. These are examples of what the team is currently considering a 1, 2, 3, 5, 8 and 13. These play right into the inspect and adapt loop of scrum and Agile product management. As teams mature and change, their capacity and knowledge will as well. What once was considered a 3, may now be a 1, or maybe something that was a 5 is a 13 for the team these days. Calibrate your guiding lights and compare tickets as they are quoted against those examples. When needed, replace the guiding light with a new one. This will open up a ton of potential for scrum mastering, team building and increased productivity and predictability that lead to profitability.
Story Points in Action
In this example, let’s assume a small product team with three devs and a product lead. They’re working to create a better car and have come up with a feature that makes you a latte while you drive. (Excellent!) The work has been completely defined, and our three brave devs are ready for it. The next step would be breaking that work down into smaller bite-size stories. Each story can then be quoted. For example, when it comes to installing the coffee grinder maybe the dev estimate was 5, 5, 13. The next step would be having a conversation for the dev who said 13 and the two that said 5 to explain their reasoning. This can often illuminate issues in the story like missing details or incorrect assumptions that can save time and money too.
As a second example, let’s consider a software product team with technical debt. This is work that needs to be done to the code, architecture or infrastructure that doesn’t directly impact the client but may save the company time and/or money. These issues can be hard to prioritize and justify. With the story point process, our same team of three devs can break down the work to be accomplished and quote it with story points. This allows the product teams to plan it out and pay that technical debt slowly over time or knock it out with a single sprint of work.
Implement Story Points (Correctly) Today!
With all things scrum/agile, it’s a team of individuals. To change an estimation process or implement one when there hasn’t been one before can take time. It requires each team member to understand why the changes are needed and the benefits of implementing them. Provide some training docs or articles like this one to your team and leadership or find a good YouTube video breaking them down.
The next step is selecting the guiding lights for your estimation process. Remember these can and should change and the goal is to compare estimates while they are made to the guiding light tickets. This establishes a good habit for the team. The consistency gives you a clear metric on predictability (planned vs done) and productivity (story points completed per sprint). These metrics can be paired with budgets to further detail products and align development efforts with financial goals and budgets.
Always inspect and adapt. That one’s pretty simple but can be overlooked. The work of “improvement” doesn’t stop; it only changes. Constantly reassess your guiding lights and make sure the team is learning to create better more accurate relative estimates. Your product will grow positively from these efforts, and it will get your dev and product teams on a good path in no time with a clear way to discuss improvement and process.
Conclusion
Just don’t estimate with fixed time-based numbers. That’s the morale of the story here. It’s bad practice, inefficient, inaccurate and old-fashioned. Relative complexity/effort-based estimates provide increased value while decreasing perceived pressure on dev teams and easing conversations around deadlines and timelines. A good story point process is crucial to estimating and planning for an Agile product manager. Embrace the story point, embrace the “abstractness” and stay Agile!