Quick Tips for Story Sizing in Agile Design and Development
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?
I recently asked the Think team for some advice about the straightforward methods they’ve used to size stories in Agile design and development projects. I was looking for uncomplicated ways to size stories, but something more detailed than basic T-shirt sizing, to use as a guide to help get our team aligned. 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 on our internal team.
1. Pick a Consistent Story Point 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 of 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 sizing.
Agile is all about continuous improvement-and making the framework work for your specific needs, not the other way around.
More tips from the team:
- “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 Sizing that Fits your Team and Needs Best
There’s no one-size-fits-all approach to story sizing. 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. One person’s interpretation of what “small” means needs to align with everyone else’s. And one person’s understanding of what a “3” means needs to be understood and shared by the team, so that when someone says “this is a 3,” the rest of the team assumes it will be finished in [x] number of days from the day the effort starts. 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 the team:
- “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 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
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:
- “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. At the End of a Sprint, Reflect on How the Estimating Worked
When you start working through stories that have been sized 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 size 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:
- “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
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. 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 and help your team work much more efficiently.
Originally published at https://www.thinkcompany.com on January 14, 2021.
