Decomposing Story Points estimate to frontend, backend etc..
Hello everyone,
We have a crossfunctional team with 2BE + 1FE + 2QA developers.
The team just started to use planning poker to collectively estimate stories and tasks with Story points (taking into account volume,complexity, uncertaincy).
Dev manager additionally wants them to split this pie of e.g. overall 8 story points between specializations for each story/task. Say 8SP = 2SP FE + 4SP BE + 2SP QA
Dev manager main objectives are 3:
- Track how much of complexity a single developer handles, to eveluate individual performance, detect who is constantly "underutilized" or slack too much etc.
- Have objective data to protect his direct reports from being called as "lacking commitment or underperforming". There is a story that goes before I started as an SM in the company, where Dev manager received complains from other people and didn't have any metrics in place to agree or disagree with them.
- Help PO better plan new features, since some features can be backend-heavy and some are mostly frontend. With overall estimate we don't get this understanding.
The (3) one doesn't feel like horrybly bad intention for me. PO could benefit from such info if that was possible.
But I don't feel that SP can help with (1) and (2). I feel this change of practice can do more harm than good and lead to unpredictable results, since estimates can be manipulated by the team members to "look good" in front of Dev manager.
And the whole concept of team velocity goes south.
So I disagree with the Dev manager on changing SP estimation but I can relate to his pain too.
What would you suggest in this situation? Any short term and/or long term solutions to cover 1-2-3 and let SP alone?
Thanks!
It sounds like you've got a "Dev manager" who is undermining the cross-functionality of the Developers and their ability to self-manage their work, and to be jointly accountable for it. That's the problem which is being exposed.
In addition to what @Ian said, it also exposes that your organization does not know what Story Points actually mean. For that I refer you to this post by Ron Jeffries.
It is also obvious that your organization does not understand that measuring the value being delivered to the stakeholders is more important than measuring the number of hours a person sits at a keyboard. For that I refer to the Evidence Based Management guide here at scrum.org.
An estimate is a guess made at a specific time based upon the information that is available at that time. Once work begins, new information becomes available and the original estimate is no longer valid. So evaluating peoples performance based upon the guesses that they made before they started to work is not going to accurately reflect their performance. And as you said, it will probably end up in the developers gaming the system by providing large estimates and they will not want to work on anything that they did not estimate themselves. So it is going to lead to each person picking a specific item from the backlog, giving it their own estimate and refusing to work on anything that someone else has estimated. The backend developer will provide a large estimate, the front end developer will provide a large estimate, the QA will provide a large estimate. And then they will all want to add them together to get a "consolidated" estimate. The estimates are going to be very large because they are being judged based upon portions of them.
As Scrum Master this is your challenge to change the perception of the people involved so that they better understand the empirical nature of Scrum.
What are the Developers saying about this? Do they also share these concerns? How are they addressing the Sprint planning considering the skills distribution?
Challenging the organization is part of the work of a Scrum Master. Why gets the dev lead the complains? Which complains? Was there a missing Sprint Review to communicate the outcome of a story. Was it already bad planned as for the story the customer focus was missing? Was there no communication of the developers and possible stakeholders?
As already mentioned above, SP to compare performance is as you already mentioned a complete wrong approach.
In general, the all develoopers are accountable for the commitment and if something went into a wrong direction, this needs also to be discussed in the team (as soon as possible). Do you have a good level of trust from outside to and within the team? How good are the discussion culture and the scrum values in the team?
Why does the dev manager has his focus on performance counting instead of supporting the team(s) to get better?