Developer: “Last Sprint I delivered 18 story points all on my own!”
This post will not be about story points. I will leave the story points are evil discussion for another time. Instead I want to focus on the intent behind such a statement. And by intent, I am referring to the proud declaration and feeling of accomplishment and success.
Is 18 points something to feel good about? Is it something to be proud of? Well, for this team, no other developer had done that in a single Sprint. So maybe… But a statement like this reflects a deeper misunderstanding about Agile culture, values, and principles.
First, points are not a deliverable, yet I run into many teams that use such language. More importantly though, Agile teams work together as A-team. Meaning they collaborate, pair, and help each other throughout the Sprint with a focus on delivering on the Sprint goal that is tied to an overall vision. The focus is on customer outcome and not individual or team output. In Scrum, team members are proud about team accomplishments and delivery of customer value, not individual tasks, and heroics. So, it is great that this developer was able to deliver 18 points on their own. But did the team achieve its overall Sprint goal? Is the customer pleased with the product increment? Did we even deliver a product increment? If so, then that is what we should be proud about and all our collective contributions that led to that. If not, then why not? Could it be that developers were working in their own silos, focusing on finishing what was on their plate instead of helping each other out? Was the focus on accomplishing individual tasks in detriment to the overall Sprint goal? Was there even a Sprint goal or was it just random things to do?
As Scrum Masters, keep an eye out for such language and behavior. Remind the team of the Agile values and principles as well as the Scrum values. In particular, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and the Scrum values of Focus, Courage, and Commitment. The development team should focus on the Sprint goal, have the courage to speak up and ask for help, and make commitments to each other on accomplishing the goal. As a Scrum Master, you have to help the product owner and the scrum development team come up with cohesive Sprint goals that lead to product increments and then reinforce the focus of the development team on the Sprint goals and not the individual tasks and user stories.
- Tales of the Bizarro Scrum
- Tales of the Bizarro Scrum – Developers and Deliverables
- Tales of the Bizarro Scrum – Are You Sure It’s Going to Take this Long?
- Tales of the Bizarro Scrum – The BAs are Holding Us Back!
- Tales of the Bizarro Scrum – Yes, We Are a Self-organizing Team
- Tales of the Bizarro Scrum – Assigning Points to Everything
- Tales of the Bizarro Scrum – Isn’t Scrum Just a Team Level Thing?
- Tales of the Bizarro Scrum – The Code Freeze
- Tales of the Bizarro Scrum – Refining the upcoming 8 Sprints?
- Tales of the Bizarro Scrum – Of Course We Are Agile!
- Tales of the Bizarro Scrum – I’m Responsible for Writing User Stories
- Tales of the Bizarro Scrum – Scrum Master Canceling the Daily Scrum
- Tales of the Bizarro Scrum – The Sprint was a Colossal Failure
- Tales of the Bizarro Scrum – When is Sprint Planning?
- Tales of the Bizarro Scrum – Canceling the Sprint Retrospective
- Tales of the Bizarro Scrum – Product Owner Missing Sprint Planning?
- Tales of the Bizarro Scrum – Extending the Sprint
- Tales of the Bizarro Scrum – I’m the Product Owner and Scrum Master