.png)
I recently consulted with a financial services company to assess the health of their Scrum program with an emphasis on better understanding continuous delivery, forecasting and team capacity.
Approximately $200M in annual revenue; the size of the product and engineering organization is approximately 90 team members including engineering, QA and product development. As part of my assessment, I consistently observed five anti-patterns common amongst the Scrum teams in both enterprise and start-up environments. Unfortunately these anti-patterns are not unique as I’ve observed them with other teams and I’ve coached teams in overcoming these obstacles.
Settling on the average is a quick way for teams to form consensus and move on to reviewing the next user story, unfortunately if you’re using this approach to estimating, you’re almost guaranteed to underestimate every time.
“A three point estimate from development and an eight point estimate from QA does not make a five point story”
It’s important for teams to have the discussion of why the disparity between the estimates and to settle on an estimate that has been well vetted through thoughtful discussion and analysis. In the absence of this discussion, we negate the effort of the team member with the most work (in this case QA) and we inadvertently commit to doing eight points worth of work communicating five points of effort.
For example, If your team has a velocity of 24 points per sprint and you have 3, 5 point stories that should actually be 8 point stories, you’ve just committed to doing 24 points of effort and communicated that you have 15 points committed in the sprint and bandwidth for 9 more points. Your team is already at velocity and adding anything else to the sprint will over commit the team by the total effort of the additional stories, assuming your estimates for the additional work are reliable.
If you’re currently estimating using this anti-pattern, you could be over committing your sprints by a lot more than you think and it’s highly unlikely that your team velocity will stabilize anytime soon.
Deferring to the estimate from the most senior member of the team is not uncommon for Scrum team’s and often leads to fairly consistent outcomes. However, the issue with this approach is that the most senior member is often the team’s lead developer and unfortunately this approach negates the collective effort of the entire team.
This estimating approach will often suffice if your user stories are typically more focused on development and less on QA. However this approach quickly breaks down when QA efforts exceed that of development. For example, efforts on the part of development might be minimal or average for a particular feature, however heavy regression, automation and testing across web and mobile on the part of QA might be exhaustive.
Additionally, this method to estimating breaks down even further when the development team member that will inevitably own the user story, is not the lead developer and does not have the domain nor architectural knowledge to complete the story within the original estimate as provided by the most senior member of the team.
In agile it’s important to focus on outcomes and not output, and if your goal is to get through as many user stories as possible during user story review then you’re missing the point. The outcome of user story review is to collectively discuss bodies of work that the team will commit to and be held accountable for.
Output is when we can say we estimated five user stories during user story review. Outcome is when we can say we estimated one user story, by breaking it down into three smaller stories.
If you’re currently estimating using this anti-pattern, you could be missing out on a wealth of opportunity for knowledge share amongst the team and the ability to create a more autonomous team.
Skipping the definition of done is such a lost opportunity and a common oversight by many teams. Unfortunately this oversight often leads to a number of pitfalls including user stories that rollover from sprint-to-sprint, unrealistic estimates, velocities that struggle to stabilize, and more importantly, scope creep and team frustration.
The definition of done is a crucial conversation, and yet teams often squander this opportunity for the sake of expeditious meetings and the illustrious quest to return to our desks to do “actual work”. Unfortunately it isn’t until mid-sprint that the team begins to understand the true scope of the user story and soon realize that they are not aligned.
The definition of done helps each member of the team understand what done means to them, but more importantly it defines what done means for the team. It’s the conversation that occurs in order to determine what is in and out of scope and it places guard rails on the requirements and helps with managing scope creep.
The definition of done helps teams develop and maintain consistent velocities based on holistic conversations centered around development, testing and deployment, and it avoids conversations like “well, I’m done but not done done” or my personal favorite, “it works on my machine”. Great! We’ll just point prod to your machine and call it good!
The 2020 Scrum guide defines the definition of done as:
a formal description of the state of the Increment when it meets the quality measures required for the product….it creates transparency by providing everyone with a shared understanding of what work was completed as part of the Increment. If a product backlog item does not meet the definition of done, it cannot be released or even presented at the sprint review. Instead, it returns to the product backlog for future consideration.
Team and organizational alignment is a challenge in itself, but it doesn’t have to be made more complicated by avoiding the conversation around the true scope of a user story. If you’re currently estimating using this anti-pattern, you’re sacrificing team alignment and you’re doing a tremendous disservice to the betterment of your team.
I’m all for stretch goals and setting the bar high, but is it really possible to have a single user story with that many points? In my years of coaching I’ve seen backlogs filled with user stories that vary in point values ranging from three points all the way up to forty points for a single user story.
These are user stories, not epics, and there is a big difference between a three point user story and a forty point story. To argue that I could lose three pounds in two weeks is vastly different than arguing forty pounds of weight loss in the same time period. When estimates seem unrealistic they likely are.
If your team has yet to complete a user story with a large estimate in a single sprint, then you need to ask why? You want to understand root causes to unrealistic estimates:
Large user stories need to be broken down into manageable effort, effort that can be completed in a given sprint. Properly estimated user stories lead to completed user stories, and completed user stories represent a sense of accomplishment.
There is nothing more disheartening for a team than seeing an underestimated user story roll over for multiple sprints. This type of anti-pattern often leads leadership to question the effectiveness of the team, the effectiveness of “being agile” and it displays a lack of progress, leading to frustration and a lot of difficult conversations.
If you’re a Scrum Master and your team is exhibiting this type of anti-pattern then you need to be asking why and what can we do to correct these issues.
If your team is caught in the trap of equating user story points to hours or days please stop. This approach is insanity and in my many years of coaching teams, I have yet to find this to be an effective approach.
One point does not equal one hour, nor does it equal one day. One point is equal to one point of similar effort, and the value that you place on that effort can be any Fibonacci point value you choose, just so long as the team is aligned on what the value of a point represents to them as individual team members, and more importantly to the team as a whole.
The beauty of story points is that they are not absolute, yet they represent a baseline that the team has agreed to recognize as a starting point for the conversation around scope and the definition of done.
Points to a Scrum team are currency against the work to be completed and they hold tremendous value. Points should be spent thoughtfully and with commitment, and when thoughtfully applied, points contribute to:
… and more importantly, they contribute to healthy autonomous teams.
The key to estimating is to keep it relative. Try this exercise with your team. Omit the point totals in the image below and have each team member anonymously provide estimates for each of the individual animals or cohorts of animals…you decide. Then at your next retrospective discuss the results with an emphasis on any particular outliers.
Jim Apodaca is an OKR Coach, Agile Strategist, and Change Management Leader. He helps organizations scale and execute operational growth strategies in the areas of agile development and organizational transparency using OKRs and Scrum.
.svg)
.svg)
Free 21-day access when you sign up...
.jpg)
.png)
.png)