Contents
The day we will stop talking about estimation and arguing over story points is not today among the Agile community.
After my article on estimation the cumbersome eternal debate I thought I would be done talking about estimation for a while.
I was wrong!
A few days ago, I was randomly scrolling on LinkedIn like I do some days when I want to stop shaming myself over looking at cute cat videos on Instagram when suddenly a post grabbed my attention.
It was a post regarding SAFe® and their “recommendation” for “Starting Capacity for New Teams“. The part of the article that interests me is buried in this article on iteration planning.
Disclaimer before continuing: I am not against SAFe®. I am not for SAFe® either.
My opinion around SAFe® is the same as for any framework. SAFe® is a tool and as such, it can be used in really awesome ways and really poor ways.
I confess that when I found the post from Joe Barretto, I thought it was a joke or an April’s Fool post.
It was not.
Joe was relaying what is written in SAFe® and took my comments very well which inspired this post.
Joe seems a fantastic person, and our exchange was made in the most respectful way, which I loved: thank you, Joe!
So what is this all about?
“When the team is new and the average velocity is unknown, one method for initially forecasting the team’s capacity is as follows:
- Give the team 8 points for every full-time developer (including test, etc)
- Subtract one point for every team member’s vacation day, holiday, or other non-working days in the iteration.“
What is team velocity?
According to Scruminc: “Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.” The “Points” referred to “Story Points”, more on this in a moment.
Velocity is a lagging metric, meaning we start having an idea of what a team can accomplish only after the team delivered value over time or, as Scrum called it, after the end of the Sprint. When starting capacity with a new team, we simply don’t have any idea about it. The team does not have historical data and cannot rely on past prediction.
Let’s take note that the Scrum guide does not mention velocity. The Scrum guide only mentions the need to inspect frequently the team’s progress toward the Product goal.
As velocity is generally coupled with the use of Story Points for Scrum Teams which SAFe® takes largely inspiration from, I understand the willingness to quickly determine a velocity for the team to know what their average capacity is.
Though, the way it is presented in SAFe® brings issues.
What makes this problematic?
According to SAFe® definition for Agile teams: “Agile teams are self-organizing and self-managing and are accountable for delivering results that meet the needs and expectations of their customers and stakeholders.”
A self-organizing team has the autonomy to choose how best to accomplish its work, rather than being directed by others outside the team.
A self-management team takes full responsibility for delivering a service or product through peer collaboration without a manager’s mandate.
By arbitrarily saying each team member represents 8 story points per iteration (which I assume is a 10 days iteration), the organization withdraws the team from its self-organization and self-management which is the core being of an agile team.
As an organization, it means “we are saying big words without following up on actions”. This can directly lead to disengagement and a lack of motivation for employees. After all, why bother if someone else will decide for us in the end…
From the same Agile teams page, I read later: “Teams become self-directed and self-reliant, have more autonomy, further enabling decentralized decision-making all the way to the individual contributor. Agile teams are more productive than groups of similar individuals, are more engaged in their work, and have more fun on the job.”
In short, imposing a predetermined amount of story points per team member per iteration takes away the team’s empowerment to decide on how it will estimate its work.
It also opens two nasty doors.
The first one at the organization level: comparing teams’ velocity.
This is one agile anti-pattern I have seen a lot across organizations.
A Story Point is a relative unit of measure for expressing an estimate of the overall effort that will be required to fully implement a piece of work. When a team estimates with story points, it assigns a point value to a piece of work. The values should not matter. They are for the team and the team only, the story points are helpful for capacity planning.
A team could estimate with the Fibonacci sequence, quite common (1, 2, 3, 5, 8, 13, 21), while another would estimate by doubling the sequence (1, 2, 4, 8, 16) and another would do it by t-shirt sizes (XS, S, M, L, XL).
The second one is at the individual contributor level: comparing the team members’ Story Points.
Estimating in story points is helpful for capacity planning to achieve the goal, whether Spring goal or Iteration goal. Achieving the goal or not needs to be attributed to the entire team, not a single individual.
This is quite clear in the Agile Alliance definition regarding teams: “The notion of team entails shared accountability: good or bad, the outcomes should be attributed to the entire team rather than to any individual.”
Attributing story points per team member opens the door to performance evaluation based on Story Points by individuals which leads to unhealthy competition between team members. I have seen this happen and it leads to team members retaining knowledge and information to achieve a better performance appraisal impacting directly the overall company business performance.
If you want to reward team members based on their individual contribution, honestly, take the good old hours. No need to disguise this as “agility” with Story Points.
I needed to lay out the downsides of what seems a small paragraph, compared to the framework’s size, but that have potentially big impacts on the organization’s mindset.
Now, let’s bring some light (hopefully).
How do I start capacity with new teams?
Buckle up! It is going to be more than 2 sentences.
When a new team starts to work together in a 2 weeks iteration (or Sprint, assuming they run Scrum) I start by having a conversation with the team members about estimation and story points.
I answer questions such as:
- What are Story Points?
- How to use Story Points?
- What are the common myths?
And, I ask:
- What is the team members’ experience around Story Points?
- How do they want to use Story Points?
For the sake of simplification let’s assume the team decides they want to use Story Points in a Fibonacci sequence. You could proceed the same way if the team decides to double the sequence, use t-shirt size, etc.
We, then, collectively look at work items in the current team backlog.
The team decides what a 1, 2, 3, 5, 8, 13, 21 story points item means for THEM, based on their definition of done (emphasizes the “them” as one team will have a certain definition of what a 1 Story Point work item is and another team will have another definition as seen above).
The team selects some work items and assigns the number of Story Points it feels are adequate.
Those work items become the new references.
Based on the new references the team compares other items in the backlog to the new references and assigns Story Points to each work item needed for achieving the iteration or Sprint goal that they feel can be done.
At the end of the iteration or sprint, the team analyses how they did toward achieving the goal and how they did toward the work items they defined as references regarding story points.
Depending on what happened they adjust their references for the future.
The important thing here is:
- Story points are proper to each team and that is perfect.
- Some teams I worked with delivered 20 story points in an iteration, others 50, and others 90 points. Did it matter? No.
What matters is if the team achieved its goal.
What matters is if the team delivered the value needed.
More on those last two sentences in another post.
Conclusion
Shall we burn SAFe® at stake? No.
Again, SAFe® is a tool and as we would not judge a knife, we should not judge SAFe® either as being a bad framework. I am convinced SAFe® positively serves a lot of organizations. What we should make sure about though is to always question. “Does this make sense for a team?”, “Does this hinder the team in its self-organization and self-managing development?”.
I am curious to know more about your thoughts on this subject.
Feel free to drop a comment or contact me directly.
If you are a Leader, a Change Agent, a Scrum Master, or a fellow Agile Coach feel free to book a 30-minute conversation with me for guidance, coaching, and/or mentoring.