5 examples of soulless Scrum Events
By: Willem-Jan Ageling
Tags: Serious Scrum, Product Management, Leadership, Agile, Scrum

5 examples of soulless Scrum Events

Scrum events without empiricism are waste

Many people think that Scrum is about rigorously having the Sprint Events. You need to have a Sprint, Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective because the Scrum Guide says so. “The Guide say so” is never a good reason. If this is your reason for having the events then probably they will turn out to be similar to the below examples.

1. Sprint Planning without a goal

The Products Owner brings forward an item that he wants to have picked up because the CEO brought it forward when they talked in the corridor in the morning. Unfortunately this is all the PO knows about it. But it’s urgent, so the team has to work on it now.

Then the IT director chips in. She also has some important items, coming from her list of technical improvements.

The Development Team doesn’t know the inns and outs of the proposed topics. It’s nothing special that these topics come out of the blue. Just like it’s nothing special that they will also have to finish the unfinished things from the previous Sprint. Except for the things that were dropped because they weren’t required anymore.

The Development Team is already happy that the Product Owner and the Director didn’t have their typical priority debate consuming the whole Sprint Planning.

2. Detached Daily Scrum

Daisy starts: “Yesterday I worked on item 123. Today I will continue to work on item 123. No impediments.”

John: “Yesterday I couldn’t work on item 456 because I had to attend all kinds of meetings. Today I will again not work on the item because of an off-site. No impediments.”

Alice: “Yesterday I couldn’t work on item 789 because of the impediment with the access rights. Hopefully I can work on that item today. My impediment is that I don’t have the access rights.”

Rosie: “Yesterday I worked on item 123. Today I will work on item 345. My impediment is that John talks so much.”

Manager: “ Hey wait! Daisy and Rosie are both working on item 123!”

Rosie: “Huh? What? Oh no! Now I wasted my time. You should have updated the JIRA ticket Daisy! It was on ‘to do’ so that’s why I picked it.”

3. Sprint Review falling flat

The team wanted to skip the Sprint Review because they didn’t have something to demo, but luckily a developer is willing to explain where he made some changes in the code and then repeat the Unit Test that he conducted. So the Scrum Master planned a last minute 15 minute demo.

Sadly though the WiFi connection dropped. In the end there wan’t a lot to show. It’s not too bad, because only some of the Scrum Team members joined the demo anyway.

4. Sprint Retrospective complain session

Some of the people from the team like this event. This is their place to blow off some steam. It’s just that no-one is really listening because they have work to finish before the new Sprint starts. It’s seen as vital that velocity goals are met.

What’s also a bit sad is that the complaints are constantly about the same thing, Sprint after Sprint after Sprint.

The team also has some people that want to remove this event from the calendar as it doesn’t add any value. Just like the demo doesn’t add any value.

5. The flexible Sprint

The team decided to extend the Sprint with a week. Not all items were done yet. They feel that they can only have a proper demo when there’s actually something to show.

What was missing in the examples? Empiricism!

Empiricism to the rescue

Empiricism — transparency, inspection, adaptation — is the foundation of Scrum.

All the roles, events and artifact serve empiricism.

“ Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection.” — Scrum Guide 2017

The artifacts — Product Backlog, Sprint Backlog, Increment — should be completely transparent. Only then the Scrum Team and stakeholders can inspect the artifacts, allowing them to adapt.

Below I show what happens when empiricism is introduced.

1. Sprint Planning with purpose

This is the purpose of the Sprint Planning:

“By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.” — Scrum Guide 2017

At the Sprint Planning you inspect the Product Backlog to determine what you will do next. There’s only one Product Backlog and the Product Owner is responsible for managing it. This creates transparency.

What adds to the transparency is that the Backlog Items are properly refined so that they are ready for the Sprint. Everyone understands what the items are about and what is required to create a ‘Done’ increment. The Sprint Planning is about defining a Sprint Goal and selecting the Backlog Items that help meet this Sprint Goal.

2. Daily Scrum with focus

This is the purpose of the Daily Scrum:

“Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.” — Scrum Guide 2017

At the Daily Scrum you inspect the Sprint Backlog to determine if you are on track to meet the Sprint Goal. If not then the team decides what to do this day to increase the chances of meeting the Sprint Goal, adapting the Sprint Backlog. This is why it is so important to have an up-to-date easily accessible Sprint Backlog.

3. Sprint Review with feedback

This is the purpose of the Sprint Review:

“During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.” — Scrum Guide 2017

At the Sprint Review you inspect the Increment to see if it meets the expectations and it will allow you to receive feedback for the Product Backlog. Stakeholders and Scrum Team all have an understanding of what the an Increment entails to make informed decisions.

4. Sprint Retrospective with plan for improvements

This is the purpose of the Sprint Retrospective:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.” — Scrum Guide 2017

At the Sprint Retrospective you inspect the team and adapt the coming Sprint Backlog to add an improvement. Teams actively seek for ways to improve their way of working.

5. Sprint to bring clarity

Although the Sprint is not an event to inspect and adapt (it is the container for the other events) a Sprint certainly helps empiricism.

A Sprint is consistent in length to have the best possible predictability of what a team can do within a week. It also adds to the transparency that stakeholders know when the events take place. Consistency of the Sprint length increases the options to inspect and adapt.

Conclusion

Scrum without empiricism is Scrum without a soul.

There’s no reason to do Scrum if you forget what Scrum is: