How can new teams quickly align to perform accurate user story estimation?
You ask ’em, I (try to) answer ‘em.
TL;DR When performing user story estimation with new teams, the goal should be to first align on what estimation scale will be used — most commonly the standard fibonacci sequence of [1,2,3,5,8] — then determine what each value represents to the team. To do this, identify historical user stories team members have completed in the past that closely align with the anticipated work the team will do in the future. Alternatively, use a few of the stories that have been refined for the next sprint or so. Next, compare each story to one another and place them along the estimation scale, aligning them to their associated story point value — these will become reference stories the team can use when estimating future work.
Q: How can new teams quickly align to perform accurate user story estimation?
The Scenario: Your team at Big Wig Inc. has just finished a big project and is riding a high — after nearly a year of development, Project T-Rex has finally been released to your customers. Early feedback is phenomenal and the team can breathe a collective sigh of relief. After a few celebratory drinks, the focus inevitably begins to shift to “What’s next?”
The next day, the CEO calls a company-wide town hall where she discusses her strategy for the next few quarters. Her plan is to streamline the web and mobile checkout process in an effort to reduce time-to-checkout and offer new payment methods to keep pace with popular credit card alternatives such as PayPal, Venmo, Apple Pay, etc. as well as expand into new global markets where traditional methods don’t always apply. As a result of the shifted focus, you learn teams are going to be re-organized.
After the initial shock wears off, you begin to wonder what this means. You’re going to have to learn a different way of working with new people. You worked with your prior team for almost 2 years and it had become a well-oiled machine. Your stakeholders loved you because you almost always achieved sprint goals, rarely rolled user stories over from sprint-to-sprint, and had a stable velocity that was as highly predictable, which made planning and making long-term commitments a breeze . How are you going to accomplish this with the new team that hasn’t worked together before?
This happens all the time. While teams should ideally stick together for as long as possible so as to leverage the knowledge of their historical velocity to better predict future output, companies often re-org and shuffle teams for a variety of reasons. Perhaps business priorities have shifted and skillsets need to be aligned in a different way. Personalities occasionally don’t gel and people need a fresh start with a new mix of team members. Sometimes people just want to learn something new, explore other areas of the business, or improve their competency in areas outside of their current scope.
Regardless of the reason, teams need to understand how to quickly align on a new way of working. An important part of this is aligning on how the work they do is estimated so as to enable accurate planning, backlog prioritization, and stakeholder management. One approach to solve this problem is proposed below.
Step 1: Identify Historical Reference User Stories
Reference user stories are a great way to quickly align on a good enough estimate by comparing the story being estimated to work the team has completed in the past and asking “is this less than, equal to, or greater than the effort required to complete the reference story?” When forming a new team, the first step should be to identify what these reference user stories will be:
- Preferred Method: Identify 10 user stories the team has completed in the past that span a wide range of effort, from a day or so to complete to an entire sprint. Try to identify stories that touched similar parts of the system or were built using the same technology that the team expects to work with in the future. Omit each story’s original estimate for the remainder of this exercise.
- Alternative Method: Occasionally the product or technology being worked on is brand new and doesn’t align with any previous work the team has done. Perhaps the team members are new to the organization and there are literally no reference stories to draw from. If the team doesn’t have historical reference use stories to use, pick 10 new ones from the team’s backlog that they believe represent a wide range of effort and are the typical story sizes the team expects to encounter in a normal sprint (i.e. — don’t select outliers that are extremely large or small).
Step 2: Baseline the Reference User Stories
Write each of the selected reference user stories on a post-it and place them on a whiteboard. Draw a large 8-to-10 ft. horizontal line on across the board. On the left side, write “Less Effort” — on the right side, write “More Effort”.
The board should look something like the image below:
Think of the horizontal line as a linear scale of effort — that is, a distance of 3 ft. is 3 times the effort as a distance of 1 ft. One-by-one, discuss the complexity of each of the reference user stories and place them along the horizontal line where they make sense relative to other user stories. If any of the stories should fall outside of the desired range, throw them away and identify new ones more representative of what the team is likely to encounter.
The board should now look something like the image below:
From left-to-right, draw hash marks at 1, 2, 3, 5, and 8 ft. label them accordingly. The board should now look something like the image below:
Finally, align each of the user stories into a corresponding story size bucket. For those stories falling between two sizes, discuss as a team which size makes the most sense — it’s not an exact science and doesn’t need to be perfect. In this example, the reference user stories may fall into the following buckets:
- 1 story point: Story #2 & #3
- 2 story points: Story #4 & #9
- 3 story points: Story #1 & #6
- 5 story points: Story #7 & #8
- 8 story points: Story #5 & #10
In just an hour or so the team can be set up with a set of reference user stories that can be used in future Backlog Refinement or Sprint Planning ceremonies to quickly arrive at good enough estimates. It’s a great way to not only align the team on what each story point value represents, but also get team members used to collaborating with one another before development begins
For relative estimation to work effectively, it’s important to continuously refine the reference stories to ensure they fit the context of the work the team anticipates in the next couple of sprints. After each Sprint Review, ask the team if the existing set of user stories is still relevant — if not, scrap the ones that no longer make sense and add ones that are a better fit.
Have a different viewpoint, follow-up questions, etc? Head over to the responses where I highly encourage a healthy discussion/debate to help fine-tune these recommendations in the name of spreading the agile love!
