BURN THEM ALL — Sprint slayer🗡️
Identify your sprint slayer 😉
Not a Game of Thrones fan? — refer Jaime Lannister to know about KingSlayer or skip this article and read my other articles
“There it is. There’s the look. I’ve seen it for 17 years on face after face. You all despise me. Kingslayer. Oathbreaker. A man without honor.”―Jaime
“He loved to watch people burn, the way their skin blackened and blistered and melted off their bones. He burned lords he didn’t like. He burned Hands who disobeyed him. He burned anyone who was against him. Before long, half the country was against him.” — the Mad King — Aerys II
For this article consider your management/PM as a Mad king who wants you to burn all sprint effort planned for the sprint. And KingSlayer is the one who will slay the sprint. Let’s understand a few things, before finding your Sprint Slayer.
- Sprint is a short, time-boxed period when a scrum team works to complete a set amount of work.
- Sprints are at the very heart of scrum agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches.
- The Product Owner discusses the objective that the Sprint should achieve and the product backlog items that, upon completion, would achieve the sprint goal.
- Choosing the right work items for a sprint is a collaborative effort between the product owner, scrum master, and development team.
Over a decade while working for various IT companies and advocating agile practices in various software/application development projects/products. As a “Silent observer”, I was able to identify a few common characteristics in almost every team which are not healthy for the project development plan and I am sure you would be able to identify that in your team as well.
The term which I am using here i.e “Sprint Slayer “- It is possible that my seniors would have thought of me as their Sprint’s Slayer when I was working as a Junior developer 😉. I believe we all grow in our life and want to see ourselves as better than yesterday. As a Pragmatic programmer, it is appreciable to accept the mistakes you made and learn from those.
Let’s wear out detective caps 🕵️ and start observing behavior and pattern in your Sprint stand-ups, planning, grooming, and retros to find out your “Sprint Slayer”
- Lengthy Standups — When your daily 15–20 minutes standup starts taking 30 minutes, not just once or twice. That means someone is slaying your sprint.
- The single developer is regularly owning engineering tasks, and the rest developers work on daily support band-aids and business-defined repeated stories. Consider Sprint as a play & developer as an actor, every good artist wants to be a PROTAGONIST at least once during a play.
- Backlog Grooming outcome single-liner user stories & tasks without description and team using them as a placeholder.
- Ticket-driven development rather than Value-driven development— You might be able to relate it, Some developers or SO are fond of tickets, their sprint deliverables are N number of tickets, not the potential value.
- Single developer review completes team PRs (Strange isn’t it), rather than promoting Peer reviews.
- Lack of Spikes & Drone Spikes in Sprint or Outcome of spike some tickets and document rather than Knowledge sharing session.
- Timeboxing sprint tasks based on single developer input rather than promoting planning poker. In those scenarios, the Scrum master behaves as a “Sprint Slayer”.
- Always look at the reviewer’s MR comments if you are getting more than three “W” which means the reviewer is not aware. The funniest comment I saw in some PRs is only
?as a comment 😂 - Individual developers repetitively add random stories in active sprint and assign them to him/herself, which were not planned in Spring Planning & not Groomed with the help of a team. If it happens regularly then pat yourself you found your Sprint slayer.
Thanks for reading! Keep learning new stuff but do remember
