A Short Story About a Scrum Team

This is a story about a Scrum Team using Scrum to develop a product, learning early and often how to optimize the value of the product for their users. While the story is about a fictional team, the application of Scrum that is shown here is realistic. Thus, this story aims to help achieve a better understanding of Scrum, especially for readers who have not yet experienced Scrum for themselves.

A Scrum Team at Amazing Decisions

Kathryn is the founder and CEO of Amazing Decisions. Her company develops digital products that help other businesses make smart decisions.

Kathryn has an idea for a new product. However, she cannot say for sure what potential users will think of her idea and the product. She’s had her share of surprises in the past. Kathryn knows that investing in an idea doesn’t necessarily lead to the desired outcomes. Fortunately, she also knows how to control this risk.

She asks Paula for help, who knows Amazing Decisions’ clients and their goals, challenges and needs very well. Paula also finds the idea promising, but also can’t predict how useful the users will find the product. Kathryn asks her to be the Product Owner and to dig deeper and gain more insight into the value of the idea and the product.

Paula immediately starts to put together a Scrum Team. For this she needs Developers and a Scrum Master. A short time later, she meets with the Developer Dana to get her to join the Scrum Team. Dana finds the idea exciting and is happy to be part of the Scrum Team. She also has a good idea of what other skills will be needed to develop the product. Therefore, she brings the Developers Daniel and Douglas into the Scrum Team as reinforcement. The four quickly agree that they want to convince Sam to join them as Scrum Master. Sam is known for being a servant leader who helped many teams at Amazing Decisions achieve their goals. Sam is also excited to become part of the Scrum Team. With Paula as Product Owner, the Developers Dana, Douglas and Daniel and the Scrum Master Sam, the Scrum Team is ready to get started.

Together they discuss starting their first Sprint the very next day. Daniel and Douglas feel a little taken off guard at first. They think that they should first go into planning to describe in detail what requirements the new product should fulfil. Sam explains to them the purpose of Scrum and how Sprints work and asks them to have confidence in the Scrum Framework and him as Scrum Master.

Motivated by Sam’s explanations and confidence, the Scrum Team meets the next day for Sprint Planning: Paula first describes Kathryn’s and her vision of the product as well as the next Product Goal. She has already recorded this in the Product Backlog which makes it transparent for the Scrum Team and the stakeholders at all times. Paula then proposes the Sprint Goal and discusses it with the Scrum Team. This gives everyone a common understanding of why they want to do this Sprint. Since the Product Backlog only contains the Product Goal at this point, the Scrum Team creates some Product Backlog items relevant to the Sprint Goal directly in Sprint Planning. The Product Backlog items describe product features that Paula expects to be useful for potential users, as well as experiments so that they can find out more about the value of the idea. Then the Scrum Team creates the Definition of Done together. The Definition of Done describes the criteria that the Increment must meet in order to be usable for users.

The Developers Dana, Daniel and Douglas then select the Product Backlog items that would fulfil the Sprint Goal and that they consider achievable in the Sprint. This selection is the Developers’ forecast for the Sprint. They take into account both their availability and their Definition of Done. Every now and then Sam feels that there are some unspoken questions in the room so he asks the team about it and helps contribute to an even better common understanding of what needs to be done. Paula is also able to answer questions. The Developers then work out a plan about how they want to achieve the Sprint Goal and create the Increment according to their Definition of Done. The Sprint Goal, forecast and plan together make up the Developers’ Sprint Backlog. The Developers visualise their Sprint Backlog so that they always have a common understanding of what they are currently working on and what they still have to do to achieve the Sprint Goal. At the end of Sprint Planning, everyone has a good feeling and the Developers commit to do their best to achieve the Sprint Goal together.

The next morning, the Developers meet for their Daily Scrum and discuss how they will use the day to make progress towards the Sprint Goal. Then they work together on the most important selected Product Backlog item. During the rest of the Sprint, they work together daily and use their Daily Scrum to inspect their progress and discuss what they will do to achieve the Sprint Goal. If they learn through their work that something can be done better than planned or if doing something differently will lead to a better result, they adjust their plan and their Sprint Backlog. This way, progress and their remaining work for the Sprint Goal always remain transparent for them. In addition to their work on the Sprint Goal, they refine the Product Backlog together with Paula and prepare Product Backlog items — features, ideas, requirements and experiments — for the next upcoming Sprints. This gives them a shared understanding of what they are likely to be working on soon.

At one point the Developers encounter a problem during the Sprint that they cannot solve on their own (an impediment). Sam supports them and with Kathryn’s help removes that impediment. Because they are able to focus every day and really give their best, they achieve their Sprint Goal.

Paula invites the most important stakeholders to the Sprint Review. Among them are some users who are very interested in the product. Sam has prepared the Sprint Review and guides the participants through it: Paula first introduces the Product Goal and the Sprint Goal. She happily announces that they have achieved the Sprint Goal. She explains the Product Backlog items that have been completed, and then the Developers Dana, Daniel and Douglas show the Increment and answer questions from the participants about it. Paula then presents what the Scrum Team wants to do next to achieve the Product Goal. Then all participants collaborate on how the Scrum Team could optimize the value of the product. The users suggest new product features and the stakeholders contribute information about market trends and competitors. However, they cannot agree on what the next step should be. Sam explains that Paula, as the Product Owner, will make this decision and will make it transparent through the content and order of the Product Backlog. Paula has gained important information by collaborating with the participants that she will use to manage the Product Backlog and potentially optimize the value of the product. Because of the transparency created by the Scrum Team, the stakeholders’ trust in the Scrum Team increases. Everyone leaves the Sprint Review with a good feeling and is already looking forward to the next one.

Before the Sprint is over, the Scrum Team reflects on their experiences from the Sprint in the Sprint Retrospective. As Scrum Master, Sam ensures that the Sprint Retrospective is productive. Together they determine what they learned in the Sprint and what improvements they want to implement to improve themselves as a team and increase the quality of their product. The Scrum Team decides to add another entry to the Definition of Done to improve the quality of the Increment. Sam helps the Developers understand that the addition to the Definition of Done will have an impact on their future work. Happy about the promising results of the first Sprint and motivated by the feeling that they have gained valuable insights about the value of the idea and about themselves as a Scrum team, the team members want to start directly on the next Sprint. They wonder what it will take to do this. Sam explains to the team that one Sprint automatically follows the next and that Sprints can be a maximum of one month long. This makes progress transparent and limits risk.

By working closely together, the Scrum Team manages to make the second Sprint just as successful as the first. Before the end of the Sprint, Paula decides to deliver the Increment to selected users for the first time. This is to provide a usable product early on and to learn more about how useful the product actually is for the users. The stakeholders are also satisfied and continue to gain confidence in the Scrum team.

As a Scrum team, they manage themselves and make the decision to bring Diana on board as another Developer.

In each Sprint, the Scrum Team delivers a usable Increment several times. Paula often decides to deliver the Increment to users, so the team gains further insight into whether the Increment really benefits them. The Scrum Team also continues to gain experience and maturity. The regular inspections and adaptations as well as the transparency regarding the goals and progress further motivate the Scrum Team.

As CEO of Amazing Decisions, Kathryn is grateful for the effective Scrum Team and the growing value of their new product. She wants to spread Scrum even more in her company in the future and improve the organizational environment. To do this, she asks Sam for help …

Do you want to be successful with Scrum?

We hope that this story has given you valuable insights about Scrum. If you want to learn more about Scrum, our professional Scrum training might be a great start. Contact us!