“What is the purpose of scrum artifacts?”
“To increase transparency.”
“Well, if everyone has access to all documents on the confluence project, isn’t it already 100% of transparency?”
“No, because some pieces of information can be understood only by the team members. High transparency means that the team conveys information to other people engaged in the project in a form that is understandable by them. Most of the things don’t need any explanation but some are understandable only by the development team, for example, backlog elements. When the team estimates something in story points, they refer to some reference task that defines what one point is. No one outside the team can know how many “one story point” is if they don’t have proper technical context about the reference task. Therefore, story points estimation is useful only inside of the team. If you want to show your work to anyone from the outside, don’t use story points, because in the best case it will provide no value and in worst case misinform other people and lead to conflicts.”
“But our higher management needs to know if we are working productively enough and if the project is still on time. What will we tell them if we won’t present this simple number of burned story points / planned story points for the sprint.”
“This is the exact reason why everyone has so many problems with story points and reporting - it’s a tool that never meant to be used in reporting. I had project managers with never-ending dilemmas about them:
- How to explain to higher management that we changed the reference task and fewer story points doesn’t mean that we started working less?
- Can we change story points of a task during the sprint if it turn out harder that we thought? If yes, what should we do with sprint total points and burndown chart?
- How to explain that delivering 20% fewer story points than in the previous sprint doesn’t necessarily mean that we have been working 20% less?
- If the task is almost completed and has to be finished in the next sprint, how to treat its story points - do we add 80% of its story points to this sprint’s burndown chart and leave 20% for the next? Or should we create a new task with 20% of story points to finish the job?
Question like this will be being asked indefinitely and never clearly answered because they result from a fundamentally inconsistent situation that story points are used as a reporting metric.”
“Then why everyone is doing this and tell that it works ok for them?”
“In every single project I’ve been working on, we’ve been always “painting the grass green” when it comes to reporting. It wasn’t in malicious intents, on the contrary - we wanted to “fix” our reporting to better suit the reality - “we can’t show them sprint report like this” we thought and before publishing it, we’ve been implementing small “corrections” - adding story points to tasks that turned out harder than planned, adding new tasks for unplanned things we had to do, etc.
And then, the same people that every sprint manually correct their metrics and estimates to make them represent the reality, argue with me that my estimations fail only because I don’t have enough experience. Their experience don’t make them better at estimation - they are better at cleverly and unnoticed changing these estimation results to keep our managers satisfied.”
“Ok, but how the reporting should work? Do you want to switch from story points to man-days?”
“No, the right solution always have been around, in the Agile manifesto:
7. Working software is the primary measure of progress.So your reporting should only consist of presenting working software increment that your team has committed to deliver during the sprint. You either deliver a working sprint goal or not. There isn’t any more reliable method than that. Coming up with some imaginary points may trick the higher management into a sense of control, but it’s certainly not a good measure for the real work done.”
Sincerely yours,
~Marek