When you’re first starting work on an Agile team, it’ll usually take a few sprints to get into a rhythm that feels natural—especially when it comes to figuring out each team member’s capacity. A story points system will help your team to assign a numerical value or label based on perceived size or effort of an initiative, and assign a number of those stories based on what you’ve determined someone can realistically complete in a given sprint.
For example, let’s say you don’t want any one individual to take on more than 20 points total in a two-week sprint. In the beginning, there’s a real chicken and egg dilemma—if you don’t know how to properly assign points to a certain story or task, how can you decide how much is feasible to take on?
We recently asked the Think team for some advice about the straightforward methods they’ve used to size stories in Agile design and development projects. The following tips came out of a team discussion on how we’ve used various methods to size stories and efforts, both with our clients and with our agency.
What are Story Points?
You might be asking—what are story points exactly? Story points are metrics (numerical values) that account for both the complexity and effort a task will take—not solely the time. For example, a low story point estimation might mean that the task is simple, straightforward, and less time-consuming than a task with a high story point estimation. Considerations like risk, complexity, and repetition to be included in the estimation process. Is there a risk of dependency on stakeholders or third parties that could skew the timeline? Is the task difficult to complete? Is your team familiar and comfortable with the feature and has a leg up on the task? Using story point estimation in Agile will help your team become more nimble when managing sprints and reduce the risk of scope creep, ultimately keeping your project on track.
Agile Story Point Estimation Example
Let’s say your team is working on designing and developing an employee portal for an insurance company. They’re working through their agile story estimation process for the research phase, which includes stakeholder interviews and data analysis. They’ve given the stakeholder interviews a higher numerical story point estimation than data compilation, but why? The effort of scheduling and securing time with each stakeholder makes this a higher-risk task because the team is depending on multiple outside sources and schedules. In contrast, the data analysis has a lower numerical story point estimation because it will be completed in-house by your team of experts who do this on a regular basis.
1. Pick a Consistent Story Point Estimation Baseline
You can estimate sizes based on effort or time, but your team should agree on a consistent baseline and expand from there.
One useful activity, whether you’re just getting started or are looking at stories in a previous sprint in retrospective, is to line up all the stories on a sliding scale based on how easy or complex the story is or was to complete. Once you’ve ordered your stories, overlay a Fibonacci sequence or series of T-shirt sizes. Anything at the far left side of the scale (or “easy”), give a “1.” Anything on the far right (more complex), give a “13” or more. Stories that were so complex that they weren’t completed or felt like they exceeded 13+ should be broken down into smaller, bite-sized chunks to increase the likelihood of successfully completing them in future sprints.
Once your team is working in the sprint, they may realize that tasks and initiatives were simpler or more complex than originally thought, and you can apply that knowledge to future story point estimations.
Agile is all about continuous improvement—and making the framework work for your specific needs, not the other way around.
More tips from our agency on story point estimations:
- “One thing you can do is create a baseline story that everybody can agree is a medium-level effort—like a ‘3.’ Then, you can compare all future story estimates against that by going lower or higher.” – Drew Christiano, Design Lead
- “You can try to estimate what T-shirt sizes look like in days, often no less than half-day increments. So, ‘small’ would be a half-to-full day effort, ‘medium’ would be a one-to-two-day effort, and ‘large’ would be a three-to-five day effort. Then, break up anything over a ‘large.’” – Dan Singer, Senior Experience Designer
2. Agree on the Story Point Estimation that Fits your Team and Needs Best
There’s no one-size-fits-all approach to story point estimations. There are a few ways to come up with rough estimates for sizes, but it’s key that the team work together to reach consensus on why stories should be sized a certain way.
Everyone on the team needs to be on the same page about what sizes mean in terms of how feasible it is to complete an effort within a sprint. Rarely does any project task live in a vacuum. Including everyone in the conversation about how to assign story points will ensure that estimations are more accurate. Each team member brings a different perspective—for example, the design and development team needs to review what might seem like a simple design change to ensure it doesn’t impact the amount of time or even feasibility of the development process. Just because it looks like a small change on the screen doesn’t mean it’s that easy in the code. Everyone should be aligned and share expectations around the feasibility of each story being completed or handed off in the estimated amount of time.
More tips from our agency on how to assign story points:
- “Identify a quantifiable task your team did (e.g. ‘design and build the taskbar’), and use historical data to scope out the effort for that task together.” – Phil Charron, EVP
- “Also, you can take the next 5-10 features in your backlog, sort them as a team in order of ‘biggest’ to ‘smallest.’ Discuss as a team why you ordered them in that way. (Oh, that one is definitely ‘big’ because we don’t have APIs to get that data. Great! Availability of APIs can be used as one data point to evaluate the effort of future features.) As you do this, you’ll start to develop a common vocabulary and understanding of what makes something big vs. small, and in between—and be able to reference the exercise and conversations when evaluating future features.” Phil Charron, EVP
3. Spread out the Effort for Agile Projects
You can use stories to make sure that the team is sharing effort across the available bandwidth. This means that everyone should agree how much capacity they can take on, points-wise, during each sprint.
It’s okay if one person is always taking on an 8-point story each sprint (a larger effort that may take two weeks), while someone else takes on two 3-point stories plus a 2-point story (in which each story may take 2-3 days each). Maybe one team member has more of a design execution-type role, so they’re more likely to have 20 points each sprint, but someone in a higher-level role with more directional responsibilities may take on 5 story points each sprint.
Success here is all about 1) open communication in keeping team alignment and agreements, and 2) continuous improvement.
More tips from the team on understanding bandwidth:
- “Check in with the team to make sure the goal in estimating is to ensure that no one is overloaded. That could look like making sure someone doesn’t get all of the high-effort or high-time stories – Dan Singer, Senior Experience Designer
4. Adapt Sprints Based on Past Story Point Estimates
When you start working through stories that have been estimated using the system you establish as a team, you may notice that your estimations are off, or that you need to make some adjustments.
This is a good time to revisit the stories you have completed during this sprint and drop them on another sliding scale from easy to complex. Ask yourself if you’d estimate them again the same way that you did at the beginning of the sprint, knowing what you now know. If not, it’s a good time to reflect on what exactly surprised you about this story and why you’d size it differently in retrospect. Apply these learnings to future sprint planning. Again, agile is all about continuous improvement.
More tips from the team on story point evaluations:
- “Some members of the team may report things like, ‘This one was a medium, but it took me 5 days to complete.’ Try to dig into what about that story you didn’t know at the beginning, and put that into the criteria for future estimating. Remember that you won’t get it perfect every time. T-shirt sizes and story points will shift, and that’s OK.” – Dan Singer, Senior Experience Designer
Final Takeaways for Understanding Story Points
This process is a learning experience. It can be easy for teams to get hung up on being perfectly Agile when in reality, the framework is meant to serve as a guideline to get started. If you include representatives from every department in the agile story point estimation process, think about each task as comprehensively as possible, and look back at the end result of each task to improve the accuracy in the future, you’re doing just fine. You don’t need to apply pass/fail rules for your own implementation.
Over time—if your team is working together and communicating openly during sprint cycles—the process of sizing stories will come more naturally, help your team work much more efficiently, and ensure your project stays on time and on budget.
Want to learn more about the latest in design and technology leadership? Sign up for the Think Company quarterly newsletter today.