Scrumalogies: Analogies for Scrum - Part One

Musings from Om Hemant Patel and Rachel Schumacher

Have you ever tried to explain how a Scrum concept works in a way that people can relate with? We find the easiest way to simply explain scrum is to use analogies that fit into everyone’s everyday knowledge. Shopping, biking, dining, cooking – who knew they were Scrum? We gathered together some genius analogies to draw parallels between real life and the Scrum framework. Make sure to check out Scrumalogies - Analogies for Scrum – Part Two for more!

Pulling too much into sprints?    Pulling too much into a sprint - The Overflowing Glass

Unrefined Requirements?    Unrefined requirements? - Stew versus Stew

Forecasting issues?   Predetermination or Forecasting issues? - Out Shopping

Reporting addicts? Addicted to reporting? - Just Quit

Work from outside the sprint?  Will you just work on this quick effort please? - Destination Wedding 

Pulling too much into a sprint?

The Overflowing Glass

A timeboxed sprint is like a drinking glass, the team’s capacity is the volume that the glass can hold, and the liquid is the amount of work. If you pour more water into the glass than the glass can hold, then the water will overspill and create a mess. If the team is pushed to take more in than the sprint can hold, you will end up with the same amount of drink that the glass can hold, and a mess to deal with too.

The solution: Know how much the team can complete in the sprint and prioritize accordingly. 

Unrefined requirements?

Stew versus Stew

Let’s say that you would like to have a nice stew for a dinner party. You are looking for a cozy home-cooked meal that you know that your guests will love. You don’t have time for shopping and cooking however, so you ask your family members to get the meal ready. They happily agree excited to try a new recipe. What was not taken into account, however, was what kind of stew?

 You entice your guests with promises of a nice classic American stew with all the trimmings (stewed meat, carrots, potatoes, and wonderful, buttery biscuits). At the same time, your family member is proud to show off their cooking skills with a beautiful creamed curry stew complete with coconut highlights. When dinner is served, everyone is disappointed. The cook does not receive the compliments they were expecting, you have made promises that are not accurate, and your guests are not getting that home-cooked American stew their taste buds were salivating for.

The Solution: Talk with the team on a regular basis to ensure that everyone is on the same page.

Predetermination or Forecasting issues?

Out Shopping

This is a very common pitfall that many of us face. The business needs to understand the budgeting, the ROI, opportunity costs, Estimate at Completion, etc. so that they can determine if the project is a good investment and secure the funding. However, the danger here falls under managing expectations. In all forecasting methods, there will be newly discovered work that is not accounted for in the forecast.

As a grocery shopper for today’s dinner, forecasting may not be much of a factor. Sure, you may throw in a product that you didn’t plan on buying, but generally, you will just purchase a few things for dinner. But if you are planning to stock up for the whole month, even with the most meticulous planning, you will run into a lot of extras at the store. Most importantly, you will not purchase a lot of items that you didn’t realize that you needed, and you will waste a lot of stuff that you thought you needed, but didn’t use. There will be a cost of time and budget to go back to the store and purchase those items.

The Solution: This risk is significantly mitigated if you keep the same scrum team together and if your mindset changes from items to time. Once a scrum team has had the opportunity to reach the performing stage, then it is simple to calculate an average of how much work can be completed within a sprint. As your mind shifts to time, you can understand that they will deliver x amount of product in x amount of time. What product is produced will mirror the natural flexes in the project and environment as unknowns become known. 

Addicted to reporting?

Just Quit

Google Sheets, Excel, Documents, PowerPoint slides addiction? You are not alone in this. Many of us have been using these tools for reporting for the majority of our professional lives. They pile up and finding the folder for a particular document is frustrating though. Besides, was that document ever updated? Do you have the time to create another document?  There is a better way, but it takes a mindset shift.

Almost all projects these days are managed with some sort of tool, whether it is a Jira board, Azure DevOps, VersionOne or another. There are many tools out there to use, and your team is probably using one of them. In almost every instance, you can cut out that extra documentation, and use the tool for real-time reporting.

This excessive documentation is like quitting a bad habit. Imagine that you are a smoker and you understand that smoking is unhealthy and that you should quit, but it is painful to go through withdrawals. The same holds true for an excessive documentation habit. It will require a withdrawal from the bad habit and your dedication to learning the tool. But after learning the tool and quitting your excessive documentation, you will have a fresh and real-time reporting system where all inputs are coming from one source!

The Solution: Learn the tool and ensure that the team is updating in real-time.

Will you just work on this quick effort, please?

Destination Wedding

Yep, we have all been there. Your team commits to a sprint, they are plugging away in their zone. Someone from leadership, or even an old friend, drops by and asks them to help them out really quick on this one little thing. Yikes! There are many things wrong with this. Context switching, sprint efforts, lack of understanding how much new effort it will take, the team losing its velocity, the team members not being able to account for each other’s work, potential budget concerns, black matter or unaccounted work, jeopardizing the sprint goal- the list goes on, but the effects of your team being pulled away from their current work is significant.

For this analogy, imagine that there is a group leaving a city to drive to a destination wedding in another state. They all need to take separate cars but have a very specific plan that they promise to adhere to. They leave at the same time, promising to drive alongside each other until they get to their destination. Naturally, the wedding cannot be delayed and there are a lot of activities they are expected to do as soon as they get there.

A family member asks one of the drivers to drive just a bit out of the way to a town that the group is not stopping at for a quick favor, perhaps grab some fresh peaches from a nearby town. The driver feels guilty about saying no to their family, so they agree to do it. The results are significant.

The group realizes that they have lost a car and slow down. They are reliant on that driver to help them get where they need to go for the wedding. The driver doing the favor soon realizes there is road construction or the town is further away than they realized. Instead of focusing on wedding preparation thoughts, they are now feeling frazzled and late. If they drive a few extra hours a day, they can still catch up to the group, but they will be tired and worn out. The end result is the entire group is weary, frustrated with each other, and potentially to the wedding. Worse case is that they arrive late, are rushed and do not have time to get their tuxes and dresses dry cleaned for the wedding. Quality suffers, morale suffers, their obligations may not even be met.

The Solution: Ensure that all work is determined in sprint planning and any extra work goes into a user story to be prioritized. If there are a lot of directional changes, then shorten the sprints to match the changing requirements.