Simplification Officers’ Post

How are your Developers bringing and supporting Transparency? Note: Transparency is way more than bringing “visibility”. It is about reaching ”a common understanding”. Each of the Scrum Roles exist to bring transparency to the other Scrum Team members and the stakeholders. If you feel that there is a lack of transparency for any aspect of your initiative, check who is best placed to bring clarity. So what about the Developers? Bring common understanding about what? What are the completed Product Backlog Items? “Done” means what with regard to the quality level? What process improvement will we address during this Sprint? What is work remaining for the Done Increment and the Sprint goal? And what is the likelihood of achieving this goal by the end of the Sprint? Bring common understanding to whom? To the entire Scrum Team and the stakeholders Summary: Does your Development Team bring a common understanding about the current state of the Increment? Prompt to discuss with your team: What does Transparency mean to you? How can your Developers bring even more transparency to all stakeholders? Interested in more? Watch out for upcoming posts. Don't want to miss any of these posts? You can have them weekly in your mailbox via https://lnkd.in/dmyDEqm I hope you find value in these short articles and if you are looking for more clarifications, feel free to take contact. #Scrum #Simplification #BoostYourScrum

How is your Sprint Review raising Transparency? Note: Transparency is way more than bringing “visibility”. It is about reaching ”a common understanding”. Common understanding about... ... the Increment. What is the status right now? What capabilities, features, etc. does it have? What outcomes do we expect of it as it stands? What would we need to have next? How does the market evolve for our type of product? ... Once these, and probably more, questions are answered by the team and the stakeholders based on their current knowledge and experiences - indeed, the stakeholders are part of your Sprint Review, so real users for example can provide you with lots of input - understanding, transparency is raised to levels you cannot achieve without them. Common understanding amongst who? - Amongst the Scrum Team and the stakeholders. Prompt to discuss with your team: What does Transparency mean to you? How do you use Sprint Review to raise Transparency? Interested in more? Watch out for upcoming posts. I hope you find value in these short articles and if you are looking for more clarifications, feel free to take contact. Don't want to miss any of these posts? You can have them weekly in your mailbox via https://lnkd.in/dmyDEqm #Scrum #Simplification #BoostYourScrum

How is your Sprint Review raising Transparency? Note: Transparency is way more than bringing “visibility”. It is about reaching ”a common understanding”. Common understanding about... ... the Increment. What is the status right now? What capabilities, features, etc. does it have? What outcomes do we expect of it as it stands? What would we need to have next? How does the market evolve for our type of product? ... Once these, and probably more, questions are answered by the team and the stakeholders based on their current knowledge and experiences - indeed, the stakeholders are part of your Sprint Review, so real users for example can provide you with lots of input - understanding, transparency is raised to levels you cannot achieve without them. Common understanding amongst who? - Amongst the Scrum Team and the stakeholders. Prompt to discuss with your team: What does Transparency mean to you? How do you use Sprint Review to raise Transparency? Interested in more? Watch out for upcoming posts. I hope you find value in these short articles and if you are looking for more clarifications, feel free to take contact. Don't want to miss any of these posts? You can have them weekly in your mailbox via https://lnkd.in/dmyDEqm #Scrum #Simplification #BoostYourScrum

Running a Sprint Review without customers or stakeholders 🙃 🤡 🐼 I have worked with different companies and teams and seen the Sprint Review work in many different ways. Borrowing from the Scrum Guide "The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed." I have seen teams run reviews where the team: 1) Use the Sprint Review to demo to the Product Manager ❌ 2) Demo to a wider group including the PM, Design and SMEs ❌ 3) Combines the Sprint Review with other teams in the same Product Group, more like a joint showcase ❌ 4) Uses the review to demo to stakeholders and real customers who ask questions discuss what they have seen and give meaningful feedback. 🎉 🎉 🎉 Number 4) benefits the team the most and helps them to learn and adapt the Product for future Sprints. But it is often hard for teams to create this space as they are often too removed from their customers. What are your experiences of Sprint Reviews? Whats the best Sprint Review you have ever been part of? #scrum #agile #sprintreview

🔑 Key activities of PBR are (1) splitting big items, (2) clarifying items until ready for implementation without further “what” questions, and (3) estimating size, “value”, risks, and so forth. In short form: split, clarify, estimate!!

How do you use your Sprint Backlog for Inspection? Note 1: Without transparency, one cannot perform a valuable inspection. Note 2: Inspection is about detecting undesirable variances in progressing towards agreed goals. The Sprint Backlog is inspected at least during the Daily Scrum to detect variances in the progress towards the Sprint goal. Where are we now? How does this relate to the Sprint goal we committed to? What about the committed improvement actions? Typically it are the Developers of the Scrum Team who are performing this inspection. The Sprint Backlog contains the items the team feels, and has identified so far, that need to be done in order to achieve the Sprint goal. If you take a good look at these, will these really achieve the Sprint Goal? What are the gaps? And what is not really needed...? Summary: Do you inspect your Sprint Backlog to detect variances in the progress to deliver the Sprint goal in a Done Increment? Prompt: With your entire team evaluate your Sprint Backlog. What might be missing to achieve the Sprint Goal? What might be too much in the Sprint Backlog that is not needed to reach the goal? Interested in more? Watch out for upcoming posts. Don't want to miss any of these posts? You can have them weekly in your mailbox via https://lnkd.in/dXXbGAN I hope you find value in these short articles and if you are looking for more clarifications, feel free to take contact. #Scrum #Simplification #BoostYourScrum

𝐇𝐨𝐰 𝐭𝐨 𝐜𝐨𝐧𝐝𝐮𝐜𝐭 𝐭𝐡𝐞 𝐄𝐟𝐟𝐢𝐜𝐢𝐞𝐧𝐭 𝐏𝐫𝐨𝐝𝐮𝐜𝐭 𝐁𝐚𝐜𝐤𝐥𝐨𝐠 𝐑𝐞𝐟𝐢𝐧𝐞𝐦𝐞𝐧𝐭 ? 𝐒𝐢𝐦𝐩𝐥𝐞 𝐒𝐭𝐞𝐩𝐬 :  𝟏. 𝐒𝐭𝐚𝐫𝐭 𝐭𝐡𝐞 𝐌𝐞𝐞𝐭𝐢𝐧𝐠: Initiate the refinement meeting with a clear agenda and goals. 𝟐. 𝐏𝐫𝐞𝐬𝐞𝐧𝐭 𝐁𝐚𝐜𝐤𝐥𝐨𝐠 𝐈𝐭𝐞𝐦𝐬: The Product Owner introduces all backlog items that need refinement, providing an overview to set the context for the discussion. 𝟑. 𝐃𝐢𝐬𝐜𝐮𝐬𝐬 𝐭𝐡𝐞 𝐅𝐢𝐫𝐬𝐭 𝐏𝐁𝐈 𝐈𝐭𝐞𝐦: Delve into the first item in detail. This includes clarifying the 'why', 'what', and the acceptance criteria essential for progressing. 𝟒. 𝐓𝐢𝐦𝐞-𝐛𝐨𝐱𝐞𝐝 𝐃𝐢𝐬𝐜𝐮𝐬𝐬𝐢𝐨𝐧: Engage in a structured discussion with the development team asking relevant questions. This ensures all aspects of the item are understood and clarifies any ambiguities. 𝟓. 𝐂𝐡𝐞𝐜𝐤 𝐟𝐨𝐫 𝐄𝐬𝐭𝐢𝐦𝐚𝐭𝐢𝐨𝐧 𝐑𝐞𝐚𝐝𝐢𝐧𝐞𝐬𝐬: Before moving to estimation, confirm if the item is clearly understood and ready for this next step. If not, further clarification is needed. 𝟔. 𝐏𝐥𝐚𝐧𝐧𝐢𝐧𝐠 𝐏𝐨𝐤𝐞𝐫: Apply the planning poker technique to estimate the size of the backlog item. This collaborative voting method helps in achieving consensus on the effort required.There are more ways to estimate. This is one more commonly used. 𝟕. 𝐔𝐩𝐝𝐚𝐭𝐞 𝐭𝐡𝐞 𝐁𝐚𝐜𝐤𝐥𝐨𝐠: Once the item is estimated, update the backlog with the new information and any modifications agreed upon during the discussion. 𝟖.𝐂𝐡𝐞𝐜𝐤 𝐑𝐞𝐦𝐚𝐢𝐧𝐢𝐧𝐠 𝐓𝐢𝐦𝐞: If there's time left in the meeting, continue with the next item. This ensures efficient use of allocated meeting time and keeps the process flowing. 𝟗. 𝐂𝐨𝐧𝐜𝐥𝐮𝐝𝐞 𝐭𝐡𝐞 𝐌𝐞𝐞𝐭𝐢𝐧𝐠: If no time remains, or all items have been addressed, end the meeting. Plan for the next steps and schedule the next meeting if necessary. 🔴 Checkout the Complete Scrum Master Toolkit here - https://lnkd.in/gUFsSFvR #scrum #scrummaster #agile #agilecoach

“If we do nothing to address it, how much will it hurt?” This is one of the questions I ask in retrospectives to help teams understand and prioritize the challenges they face. To visualize their answers, I like to use a “pain scale”. Each participant adds the identified challenges in their row, placing them according to their own view of the situation. If there are strong disagreements this will make them visible, so they can be clarified. It'll enable the team to get a mutual understanding of the problem. The same exercise can be used when analyzing problems impacting multiple teams. I find it often helpful to spot important systemic issues - and also to identify issues that run the risk of being neglected because they're inoffensive to most but can critically impact one specific team. As for the scale itself, it can be discrete or continuous - although discrete with fewer levels tends to make it easier in most scenarios. For discrete scales, I like to go with 1-to-5 or 1-to-10 and use something for each entry - as can be seen in the “Dragon Ball pain scale” exemplified below. For continuous scales, I tend to flag just the extremes - I love using Ripley’s “I say we take off and nuke the site from orbit. It's the only way to be sure.” for the worst case scenario. :) If you try it out, let me know how it went! #agilesoftwaredevelopment #agilecoaching #agilecoach #agile #scrum #scrummaster #scrummasters

The Daily Scrum is NOT a status meeting. It’s *not* about Developers “reporting out” to an audience like a morning roll call. It’s about the team aligning to achieve the Sprint Goal. Think of a home renovation show: the crew starts with a plan—tear down this wall, install that countertop. But the moment they swing the hammer, they discover mold behind the wall. Now they’ve got to pivot. The goal (a beautiful new home) hasn’t changed, but the plan needs to—mold remediation just made the to-do list. That’s what the Daily Scrum is: a time for Developers to inspect progress, adapt the plan, and stay on track toward the Sprint Goal. It’s team-to-team, not team-to-audience. Stop turning the Daily Scrum into a status report. Tear down that wall and build something better. #Scrum #Agile #DailyScrum

How is your Sprint Retrospective raising Transparency? Note: Transparency is way more than bringing “visibility”. It is about reaching ”a common understanding”. Common understanding about... ... how the Sprint went. About which actionable improvements the Scrum Team will take on in the next Sprint. What do we feel worked well? What do we want to improve? What actions will we take for this? While supporting teams I often see in the beginning that the team members stay at the surface of what happened, not wanting to hurt the feelings of the colleagues. Yet it is important to raise the understanding of what all team members have experienced and how to move forward together. The Scrum Values do help here - more on how these support transparency later. Common understanding amongst ... the entire Scrum Team: the Product Owner, the Developers, and the Scrum Master. Prompt to discuss with your team: What does Transparency mean to you? How do you use Sprint Retrospective to raise Transparency? Interested in more? Watch out for upcoming posts. I hope you find value in these short articles and if you are looking for more clarifications, feel free to take contact. Don't want to miss any of these posts? You can have them weekly in your mailbox via https://lnkd.in/dmyDEqm #Scrum #Simplification #BoostYourScrum