ScrumBut are reasons why a scrum team does not apply or benefit from the Scrum Framework. Every activity in scrum is designed and have a distinct purpose. When a team is not optimize to use scrum the way it is designed you will see some aspects of transparency, inspection and adaptation is compromized in the team.
Here are examples of ScrumBut:
- We do Retrospective but it does not bring anything new, we discuss the same old problem again. So we just do retrospective once every month.
- We do Daily Scrum but it’s too much meeting. So we only do it two times a week.
- We do estimation but only with lead developers.
- We have peer review as part of our Definition of Done, but we sometimes skip it because we have time pressure. The code written by our lead devs is good enough so peer review is unneccessary.
- We do Product Backlog prioritization but by our BA on behalf of the Product Owner. The Product Owner is not involve with our detail activities anyway.
- We do Retrospective but without our Product Owner because he/she does not have time.
- We do Sprint Review but stakeholders are too busy to attend so only the dev team is invited.
- We do story slicing but only with senior team member. New team members do not have enough understanding about what the story is about.
- We have DoD and DoR but it is not formally agreed nor written anywhere. Of course we expect everyone to know them by heart.
- We have a Product Backlog but we also have a backlog for bugs, technical backlogs, backlog for analysis, and other backlogs.
- We assigned team member to all stories upfront before we start the sprint. This way we know what everyone is going to do.
- We have a Product Owner but he/she does not have time to write user stories nor attend all our scrum events.
- We have team member in our Scrum team but he/she is only 50% for this team. He/she spends 50% for another team.
Could you identify any other ScrumButs that you see in your team?
- Scrum vs ScrumAnd vs ScrumBut: Which One Are You Doing?