Scrum. On the value of story points.
Sergey Dmitriev
Growing a Venture Builder and an R&D hardware engineering firm helping our clients create prototypes and solving unsolvable engineering problems┃Certified Scrum Trainer┃Speaker
Below you see a message from the Scrum Master of one of the teams I work with.
Sergey, hi
We have a question/controversy here.
Once at the grooming, PO said the phrase that "8 story points cost X thousand dollars.” At the retro, developers admitted that they didn’t like this phrase, because they treat story points as a relative estimate that allows them to understand how many user stories will fit into the sprint.
And the conversion of the story points to money, depresses them, and exerts some kind of pressure. And that in this case, it would be worth giving all the user stories to those who will do them faster. PO, on the other hand, believes that there is nothing bad in the fact that developers see the real price of the story points.
I understand that PO and the developers just see different sides of the same coin, and in fact, this is logical. At the same time, I would not want to turn this story into some kind of global problem, it would be cool to just agree that everyone has their own truth and everyone loves each other and everybody is fine)
PO advised me to contact you with this question.
Thank you in advance!!
Here is my reply to the Scrum Master:
Hello
I want to highlight the main postulates around which I want to talk in more detail:
1. 8 story points are X thousand dollars
2. depresses them, and exerts some kind of pressure
3. give to those who make them faster
4. everyone loves each other and everyone is fine
Step 1. Let's start with point 4. everyone loves each other and everybody is fine
As a Scrum Master, this is your starting point. You want to create a shared ground for the conversation. Remind all participants that our goal is for everyone to love each other and for everyone to feel good. The dance starts from here.
Step 2. Move to point 1. 8 story points are X thousand dollars.
The product owner made a calculation of the approximate cost of a story point. Roughly it can be calculated like this:
We take all salaries of all team members. 8 people on the team receive 10 thousand dollars a month each, a total of 80 thousand dollars a month, and if we have 2 weeks sprints, this means that each sprint costs us 40 thousand dollars. If a team makes an average of 20 story points per sprint, then 40 divided by 20 gives us 1 story point “costs” 2 thousand dollars.
This knowledge is very useful for us as a team. It helps us create various reasoning like:?
the client asks us to develop a certain feature, we estimate it at 5 story points, thus the development will cost the client 10 thousand dollars. Do we think this feature is worth that kind of money? When the client will be able to get a return on investment/ recapture this money, etc?
This type of reasoning is very helpful for everyone: Product Owner, customer, team members, etc.
Step 3. Now moving to point 3. give the feature to those who make it faster
Since story points cost money, then we need to give them to those who make them faster.
This postulate is true only if there is another team that has a lower cost of story points. However, if we have team 1, whose story point costs 2k dollars, and the second team, which has exactly the same story points (to synchronize story points between different teams is another interesting topic) and their story point costs 3k, this does not mean that the second team should be fired. All the Product Owner should think about is whether this set of features is worth the money.
One team has a set of features that costs 20k, another team has the same set of features that costs 30k, and at the same time, this set of features will bring 100k in revenue if implemented. No matter which team will take the execution, it still makes financial sense and PO can give it a green light.
It is also worth remembering that there is no individual team member who can finish the entire user story. Remember that we do the estimation at the level of user stories, and not technical tasks. And in order to completely finish the development of the user story, it is necessary that each team member puts in their effort (front-end, back-end, testing, design, analytics, documentation, etc.).
Step 4. Let's move on to feelings. Awareness of the price of the story point depresses developers and exerts some pressure.
Here we need to dig deeper into our feelings and into the beliefs that awaken these feelings.
Many options are possible, and we need to discuss them thoroughly in the retro, I will give some examples:
- I am depressed by the fact that this feature costs 20 thousand dollars because I know that the real price of this feature is 10 cents, nobody needs this feature, what the hell are we wasting our money on? If we have thoughts like that, then we need to rethink the value of this feature. Maybe it really shouldn't be done.
- I am depressed by the fact that we spent 20 thousand on development, because I know I was kicking tires half of the sprint, and now I am ashamed, realizing, that I put 10k down the drain. I feel bad to admit it. In this case, perhaps, it is necessary to correct your own behaviors and not repeat them in the future.
- It depresses me that the Product Owner uses the cost of the features to “pressure” and "shame" the team in order to squeeze as much work out of us as possible. Here you need to collect examples of the statements made by the Product Owner, where the team felt the pressure, and ask the Product Owner not to use such manipulative techniques in the future.
- There may be other reasons why there is a feeling of sadness on a team, you need to ask the members of the team on the retro and dig deeper.
I hope you can use these points when talking to your team..
Do you calculate the value of story points in your work?