Like many Agile agencies, we use “story points” for our estimates. At Atomic, we believe story points are all about communication. The partnership between product owner and developer depends on it.
Product owners set the vision for what we are building. Developers figure out different ways for how to build it. The partnership between the “what” and the “how” is the engine for products that are on schedule, within budget, high-quality, and highly effective.
One key to that partnership is estimating the work. Developers understand the product goals and provide estimates of different approaches. Product owners use the estimates to decide where to invest limited resources. Story points are how we talk to each other about it.
What’s a Story Point?
At its most basic, a story point is any number that is assigned to a task so the team can talk about the amount of work. The number is a subjective measure of the complexity, effort, and uncertainty associated with finishing a task. It provides a way for people with many diverse skill sets to compare different approaches and ask questions like, “wait, what does ‘done’ mean here?” or “is it really going to be that easy?”
What Isn’t a Story Point?
A story point isn’t an estimate of time: the time it takes may be shorter or longer depending on the person assigned. It’s not necessarily consistent across teams: context is critical and a particular team’s goals and way of working together make a big difference.
Finally, it isn’t even an objective measurement: the goal is to spark discussion, so the subjectivity is an advantage, not a problem. In fact, we have tried a few different ways of defining points, and the interesting conclusion is this: it doesn’t matter how you define points as long as it leads to a discussion of value, complexity, and assumptions from multiple perspectives on the team.
How to Get Real Value from Story Points
The practice of estimating with story points at Atomic is all about the up-front discussion of the work. Of course, we look back to see where we can learn, but here are some guides on using them to go forward as a team.
Emphasize Complexity More than Time: Our experience is that story points prompt more analysis when they are about complexity instead of time. This change in viewpoint brings out more discussion about risks and unknowns, and less about who’s doing it; more discovery of assumptions and constraints, and less dependence on individuals’ workload.
Play Planning Poker: The goal of story point estimation is to get your experts talking to each other, and “planning poker” is a great way to do that. Have your team discuss the work and then give their point value estimates all at the same time. You can do this verbally, in a chat, or using a special tool – it doesn’t matter, as long as you discover peoples’ differences and explore the reasons why.
Collect Feedback from the Group: Include the whole team in the estimating process to get to consensus, promote conversations, and take diverse viewpoints into account.
Build a Backlog of User Stories: Make sure a point value is part of your “definition of ready” for user stories in your backlog. Give every story a specific value of story points according to its level of difficulty and work before anyone jumps in.
Release Planning: Talk to the team about how many story points can be finished in upcoming sprints by comparing past velocity data. Use it to make changes, manage stakeholder expectations, and establish reasonable release dates.
Iterative Planning: As the project develops, make ongoing revisions and adjustments to the estimates. Make sure the backlog is updated and represents the team's understanding of the project by reviewing and grooming user stories on a regular basis.
Monitor Progress: Track the team's investment of points and discuss how it compares to product value. Use the discussion to pinpoint bottlenecks, review constraints, check assumptions, and adjust the plan.
What We Get From Points
Here are just a few big advantages we get from our estimation practice at Atomic. We see these happening every day as part of our partnership with product owners.
Improved Team Collaboration: Story point estimation becomes a conversation among the product owner, designers, developers, testers, and other stakeholders from the entire team to get to a shared understanding.
Easier Prioritization: When the estimates are settled in a consensus point value, product owners can more confidently decide how much to invest in a given goal now or later.
Better Transparency: The whole team can understand the estimates and decisions, find simpler ways to achieve value, and discuss how a different approach would affect the plan.
Flexibility: Story points provide a low-stakes way for teams to provide an estimate, change their minds, and arrive at a simple, clear number that has meaning for everyone.
Predictability and Forecasting: After just a few sprints, the team's past velocity data makes forecasting more accurate so that product owners can explain timescales and set reasonable expectations.
Points for Partnership
How product owners and developers communicate is critical to the product’s success. We think about all of our process tools as a way to make that partnership stronger. Change how you think about story points and you might change everything. We can help. Let’s get to work.
Comments