top of page
  • Writer's pictureValentina Zanetti

Distilling Value from Each Scrum Event

How to get the most value out of each event in the Scrum Framework!


Distilling the Value of Scrum Events

The main purpose of agility is to have regular inspection and adaptation of the course the work is headed in. And that is its main vantage point against traditional waterfall planning methods. It allows you to create increments during a short period of time, inspect them and decide whether they're useful or not. It allows you to đŸđšđąđ„ 𝐚𝐧𝐝 đ„đžđšđ«đ§ đŹđšđŸđžđ„đČ.


Today I'll be discussing how each event in the Scrum framework - as the most popular framework in digital product development - enables a team to have an opportunity to regularly inspect and adapt their work to get the most business value out of their product as possible.


The Scrum framework is lightweight and simple, but rather difficult to adopt if you don't know what you're trying to get out of it. It consists of four events and the Sprint itself, during which the work is done, and which serves as a container for the other four events:


  • Sprint Planning

  • Daily Scrum

  • Sprint Review

  • Sprint Retrospective


But before you get started, you'll first need to create


The Product Backlog


Although in Scrum (or any other agile framework) you don't plan the delivery of the whole product upfront, a rough plan is still needed and that's where the đ©đ«đšđđźđœđ­ đ›đšđœđ€đ„đšđ  comes in. And you'll need a product backlog large enough to fill at least one sprint, and a rough plan for the following two or three sprints.


Creating and maintaining the backlog is the responsibility of the entire agile team. But setting a vision for the product, prioritizing the backlog and deciding what could potentially bring the most business value next is the domain of the Product Owner.


Some of the tools a PO might use to identify the main features needed for the product that will later be refined with the team:

đŸ”čBusiness Model Canvas - to visualize the mission and purpose

đŸ”čLean Startup - to minimize the cost of failure

đŸ”čCost of Delay - to make sure to build the right thing at the right time


The PO will also need to prioritize the most important features. There are many aspects of a work item that can be considered to determine it's priority (business value, alignment with product strategy, customer satisfaction, development costs, cost of delay, timeframe, risk...)


💡 A good hack here is to đ©đ«đąđšđ«đąđ­đąđłđž 𝐛đČ 𝐛𝐼𝐬𝐱𝐧𝐞𝐬𝐬 đŻđšđ„đźđž đŸđąđ«đŹđ­, 𝐚𝐧𝐝 𝐭𝐡𝐞𝐧 đ«đžđ©đ«đąđšđ«đąđ­đąđłđž 𝐭𝐡𝐞 𝐩𝐹𝐬𝐭 đŻđšđ„đźđšđ›đ„đž 𝐱𝐭𝐞𝐩𝐬 𝐛đČ đšđ­đĄđžđ« đšđŹđ©đžđœđ­đŹÂ (customer satisfaction, costs, risks...)


Some tools that are useful for prioritizing features:

🔾Critical path items considering dependencies

🔾Eat the Frog principle

🔾Must Have/Should Have/Nice-To-Have matrix considering customer requirements

🔾Even Over Statements method to handle trade-offs

🔾Eisenhower urgency matrix (Urgent & Important/Less Urgent but Important/Urgent but less important/Neither Urgent nor Important)

🔾RICE method (Reach, Impact, Confidence and Effort)


Once the main features have been identified and prioritized, the backlog is ready for further grooming and planning. However, that does not mean the backlog is 'done'.


𝐀𝐧 đšđ đąđ„đž đ›đšđœđ€đ„đšđ , đźđ§đ„đąđ€đž 𝐚 đ­đ«đšđđąđ­đąđšđ§đšđ„ đ©đ«đšđŁđžđœđ­ đ©đ„đšđ§, 𝐱𝐬 𝐚 đ„đąđŻđąđ§đ  𝐝𝐹𝐜𝐼𝐩𝐞𝐧𝐭. After inspecting each deliverable and seeing how it performs at the end of each sprint, the learnings are taken into consideration, and the backlog is adjusted accordingly, features are redefined, removed or added. That way, you are always delivering what's actually needed, not just what was planned.


Now that you have your main features ready and prioritized, you are ready for


The Sprint Planning Scrum Event


Sprint planning sessions are one of the most difficult and harrowing events in Scrum. There's a lot of information to absorb and consider, and it's fertile ground for conflicts. But still, one of the most important things for a sprint planning session is that the whole team plans together.


Of course, you'll need a product vision and some rough feature requirements to get started. This is the domain of the Product Owner, 𝐭𝐹 𝐜𝐹𝐧𝐯𝐞đČ 𝐚𝐧𝐝 𝐩𝐚𝐱𝐧𝐭𝐚𝐱𝐧 𝐚 đ©đ«đšđđźđœđ­ 𝐯𝐱𝐬𝐱𝐹𝐧.


And once everyone is aligned around the product mission, the team should groom the work items together to:

🔾Break features down into manageable vertically sliced work items

🔾Have a rough plan on how to execute the work for each item

🔾Identify the resources needed to accomplish the work

🔾Identify the impediments that need to be removed

🔾Have an idea on the effort needed for every item


When you have a breakdown on the more prominent features, you can start planning on what will bring the most value during the next sprint.


As a team, you will need to:

đŸ”čDecide on a Sprint goal and make sure it's aligned with the Product vision and goal

đŸ”čAgree on a definition of done for increments or adopt a unified DoD if there are multiple teams working on the same product

đŸ”čDefine clear outcomes - what it means to reach the Sprint Goal, what are the measurable outcomes

đŸ”čDefine what are the efforts needed to achieve the goals and how the work will be distributed and organized between the team

đŸ”čEstimate what you can accomplish during the following Sprint. You can use hourly or story point estimates, but the 𝐛𝐞𝐬𝐭 đŠđžđšđŹđźđ«đžđŠđžđ§đ­ 𝐱𝐬 𝐭𝐡𝐞 đ’đ©đ«đąđ§đ­ đ đšđšđ„ đąđ­đŹđžđ„đŸ

đŸ”čAlign between the team on the dependencies, impediments and what are the first steps to be taken for each team member


The Product Owner will be needed in the first half of the planning session, to make sure the product goals and sprint goals are aligned. For the second half, where the discussion gears more to the how, the Product Owner doesn't have to actively participate, but he does need to be available to the team for any ad-hoc questions or clarifications.


𝐓𝐡𝐞 đšđźđ­đ©đźđ­đŹ 𝐚𝐧𝐝 đ©đźđ«đ©đšđŹđž 𝐹𝐟 𝐭𝐡𝐞 đ’đ©đ«đąđ§đ­ đđ„đšđ§đ§đąđ§đ  𝐱𝐬 𝐭𝐹 đ đžđ§đžđ«đšđ­đž 𝐚 đ’đ©đ«đąđ§đ­ đ†đšđšđ„ 𝐚𝐧𝐝 𝐚 đ’đ©đ«đąđ§đ­ đđšđœđ€đ„đšđ .


And while the Sprint Backlog may change during the sprint (it actually should!), 𝐭𝐡𝐞 đ’đ©đ«đąđ§đ­ đ†đšđšđ„ 𝐩𝐼𝐬𝐭 đ«đžđŠđšđąđ§ 𝐱𝐧𝐭𝐚𝐜𝐭! So, the purpose of the planning session is to create a Sprint goal and a plan on how to reach it. And again, as with any agile practice - the plan on how to reach the goal is susceptible to change, the goal isn't.


This can be managed and achieved by regular alignments during


The Daily Scrum


During your Sprint planning session, you've established a Sprint goal you want to meet within the several weeks, and you've also agreed on a plan how to achieve this.


But imagine the following:

A better way to achieve the goal emerges when the team starts their work. Or a previously unknown impediment arises that hinders your plan.

Or the team isn't performing as anticipated due to unforeseen circumstances. Do you ignore this and blindly follow the plan you've set before your team during the Sprint Planning? Of course not!


Plans fall through more often than not, new knowledge is uncovered, new issues and new opportunities. And this is where the daily alignment comes in: 𝐭𝐹 đĄđžđ„đ© đČđšđźđ« 𝐭𝐞𝐚𝐩 đŹđźđœđœđžđŹđŹđŸđźđ„đ„đČ đ©đąđŻđšđ­ đ­đšđ°đšđ«đđŹ đČđšđźđ« đ’đ©đ«đąđ§đ­ đ đšđšđ„!


Some tips on how to achieve great outcomes out of your daily alignment sessions:

đŸ”čKeep them short, nobody needs a 45min meeting every day to pivot

đŸ”čInclude the Product Owner for ad-hoc decisions and awareness

đŸ”čAvoid technical how-to discussions, leave them for outside the daily

đŸ”čForget the three questions and ask only one: 'How much closer are we to our Sprint goal and what else do we need to achieve it?'

đŸ”čQuickly adjust course to optimize for newly emerged knowledge and impediments


Leave the in-depth discussion with individual team-members and potential story-splitting efforts for after the daily, but agree with the team members on when to align. Announce they'll be needed more for collaboration and make sure to include the extra efforts in the re-planning.


And last, don't consider your dailies as mere team check-ins. đ‚đšđ§đŹđąđđžđ« 𝐭𝐡𝐞𝐩 𝐚𝐬 đšđ©đ©đšđ«đ­đźđ§đąđ­đąđžđŹ 𝐭𝐹 𝐚𝐝𝐣𝐼𝐬𝐭 đČđšđźđ« đŹđ©đ«đąđ§đ­ đ©đ„đšđ§ 𝐭𝐹 đ›đžđ­đ­đžđ« đ«đžđšđœđĄ đČđšđźđ« đŹđ©đ«đąđ§đ­ đ đšđšđ„. They will undoubtedly prove to be more beneficial.


And at the end of each sprint, two of the most important Scrum events still remain. The first one is


The Sprint Review Scrum Event


Very often the Sprint Review is treated like a Product Demo. But this is not its purpose.


Every event in an agile environment is meant to provide clarity on the current status, illicit new knowledge, and identify potential course corrections. Even down to the daily alignments. This includes the Sprint Review session as well.


Now, during a product or deliverable demo you simply demonstrate what you've done to the stakeholders to show that you're working according to plan and that you're on schedule. 𝐓𝐡𝐱𝐬 𝐱𝐬 𝐧𝐹𝐭 𝐱𝐧 𝐭𝐡𝐞 đŹđžđ«đŻđąđœđž 𝐹𝐟 đČđšđźđ« 𝐭𝐞𝐚𝐩 đšđ« 𝐭𝐡𝐞 đȘđźđšđ„đąđ­đČ 𝐹𝐟 đČđšđźđ« đ©đ«đšđđźđœđ­.


We've all heard the stories about Steve Jobs' first iPhone demo. And there are many more, told and untold stories like that, where the Product Owner or Project Manager 'pulls the wool' over the stakeholders' eyes to make it seem like the product/project is on track.


But, by only demoing a deliverable in the 'best light possible' you deprive your stakeholders of the following:

đŸ”»Awareness of the state of their investment

đŸ”»Genuine involvement in the development process

đŸ”»Opportunities to provide valuable business insights

đŸ”»Opportunities to adjust the plan to better reach the goal

đŸ”»Collaboration with the entire team


đ€đ đąđ„đąđ­đČ 𝐱𝐬 𝐧𝐹𝐭 𝐚𝐛𝐹𝐼𝐭 đšđ©đ©đžđšđ«đšđ§đœđžđŹ. It's not about perfection. It's about knowing exactly where the product is at the moment, and how to best get it to where it needs to be. And for that, the work needs to be transparent and everyone needs to be open, honest, and collaborate.


Some tell-tale signs your Sprint Review might actually be just a demo:

đŸ”»You're navigating around (hiding) the bugs and issues while presenting

đŸ”»Stakeholders don't get the opportunity to try the deliverable hands-on

đŸ”»The presenting is done by one person, the whole team doesn't contribute

đŸ”»There's hardly any feedback or discussion with the stakeholders

đŸ”»There are no new inputs, no course-correction, and no new knowledge


This will, undoubtedly, eventually lead to distrust in the quality of the product and the team. And not only that, you're sending your team a message that they didn't do a good enough job. You'll be accumulating technical debt the stakeholders aren't aware of and just generally setting yourself, your team and your product up for failure.


Remember the third and fourth Agile Manifesto values:

🔾Customer collaboration over contract negotiation

🔾Responding to change over following a plan


Trust your stakeholders as much as you trust your team, they're people, too, not fire-breathing dragons. They have invaluable knowledge and the power to help your team create an amazing product. Don't exclude your stakeholders from the discussion. Leverage their knowledge and power.


And make the necessary adjustments to your product and to your plan. Remember that it's about getting the most out of your work, not following a rigid plan. If there's something that the Sprint Review has determined is not useful, it should be abandoned. Ignore your Loss Aversion cognitive bias and be prepared to abandon your work, if deemed necessary.


When you've completed reviewing your Sprint's deliverable, you will also need to determine the state your team is in, the effectiveness of processes and the collaboration of your team. This is done during


The Sprint Retrospective Scrum Event


The Retrospective is by far the most misunderstood, underrated and underutilized event in an agile cycle. And yet, it's probably the most important and most impactful one.


Agility revolves around one simple principle: the inspect and adapt loop. Whichever framework you want to use, it always comes back to this. And this also applies to your most important product - your team.


Improving a team's way of working together has the potential to not only exponentially improve their efficacy and product quality. It has the potential to breed innovation. It is within the team's communication and collaboration that creativity sparks and ideas emerge, and where their potential to innovate resides.


So, in short, 𝐭𝐡𝐞 đ«đžđ­đ«đšđŹđ©đžđœđ­đąđŻđž 𝐱𝐬 𝐚 đ­đšđšđ„ 𝐼𝐬𝐞𝐝 𝐭𝐹 𝐠𝐞𝐭 đČđšđźđ« 𝐭𝐞𝐚𝐩'𝐬 đœđšđ„đ„đšđ›đšđ«đšđ­đąđšđ§ 𝐭𝐹 𝐚 đ„đžđŻđžđ„ đ°đĄđžđ«đž đœđ«đžđšđ­đąđŻđąđ­đČ 𝐚𝐧𝐝 𝐱𝐧𝐧𝐹𝐯𝐚𝐭𝐱𝐹𝐧 đĄđšđ©đ©đžđ§đŹ.


And while you'll most assuredly look at ways to improve performance, quality and processes, don't forget to look at what your team can do or what influence they can exert to also:

🔾Create psychological safety for the team and room to make mistakes

🔾Improve transparency and honesty between team members

🔾Improve the team's accountability and dependability

🔾Improve how they manage conflicts (and no, avoiding them is not it)

🔾Foster better collaboration between all team members (how to enable opening more communication lines within the team)

🔾Allow more research and exploration, both for the team and individuals

🔾Experiment in a safe and non-detrimental way


When your team gets to a point where they can communicate quickly and effectively, collaborate and experiment together, and where they have the support system and safe environment to do so, you will soon start picking the high-hanging fruits from the agile tree - 𝐚 𝐭𝐞𝐚𝐩 𝐭𝐡𝐚𝐭 đđžđ„đąđŻđžđ«đŹ 𝐚𝐬𝐭𝐹𝐧𝐱𝐬𝐡𝐱𝐧𝐠 đ«đžđŹđźđ„đ­đŹ 𝐚𝐧𝐝 𝐜𝐚𝐧 𝐝𝐹 𝐚𝐧đČ𝐭𝐡𝐱𝐧𝐠 đ­đšđ đžđ­đĄđžđ«.


Conclusions


Scrum provides a simple framework to allow your team time to consider better directions, better ways of working and better delivery processes. It's lightweight and simple, but you need to know the purpose and aim of each event if you wish to garner the benefits. And, as always, with any agile framework, it's all about the inspect and adapt loop.

88 views0 comments

Recent Posts

See All

Kommentarer


bottom of page