Developer: “I don’t have much to do. I’m still waiting on the BAs to finish writing the user stories. They always hold us back!”
A comment like this highlight siloed thinking among team members. There are only 3 roles in Scrum. A Product Owner, a ScrumMaster, and a Development Team. Note that business analyst, developer, tester, architect, designer, etc. are not roles. Does that mean we don’t do analysis work in Scrum? Of course we do. Scrum emphasizes small cross functional development teams. This means the team needs to have all the necessary skill sets to take an idea or concepts and transform it into a working product increment within the Sprint. Notice here the emphasis is on skills sets and not necessarily individual roles. Meaning, the team needs to have analysis skills, development skills, testing skills, etc. These are not relegated to individuals. It is the entire team’s responsibility to help and contribute to producing the product increment in any capacity that they can. It’s the entire team that makes commitments to each other on accomplishing the Sprint goal.
So, it is not a BAs responsibility to write user stories, and there is no way they can be holding anyone back. It is the entire team’s responsibility to deliver on the Sprint goals and product vision. In fact, a BA only writing user stories leads to the anti-patterns of scrum-fall and results in hand-offs from PO and BAs determining the requirements, handing them to developers, and then developers handing off code to testers, etc…
In Scrum, the team works collectively and collaboratively. The entire team pitches in in writing and more importantly discussing and understanding the product backlog item before designing, building, coding and testing the story. No one activity is relegated to one person. Every team member helps in moving an item from not done to done. That might mean a team member with primarily development skills writing user stories, or a team member with primarily analysis skills testing an increment, or a team member with primarily testing skills helping with basic coding, and so on.
As a ScrumMaster, you have to help foster a team mentality of we are all in this together and we go to where the work is. Encourage team members to help each other out. Encourage them to regularly pair with each other to complete an item while continuously improving on their T-shaped skills, and learning from each other. This helps avoid future bottlenecks and dependencies on any one individual or specific skill.
- 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