Welcome to the Home of Scrum! ™

TL; DR: Estimates Are Useful, Just Ditch the Numbers Many people dislike estimating work items as estimates supposedly open the path to the misuse of velocity by the managers, reintroducing Taylorism, micro-management, and excessive reporting through the backdoor. To them, for example, the proponents of #noestimates, estimates conflict with basic ideas of agile product development such as self-management, becoming outcome-focused, or leaving the feature factory for good. I like to suggest a different, less ideological approach: estimates are useful at the team level, just ditch the numbers. How so? Estimation of work items is a fast way for a Scrum team to figure out whether all team members are on the same page regarding the why, the what, and the how of the upcoming work. The numbers are a mere side-effect, probably still valid to inform the team, though. (Indeed, the numbers are not intended to be used beyond the team level.) By the way, similar to the fact that you cannot “not communicate,” I am convinced that people will always “estimate,” whether they talk about it or not. 👉 Join the poll and the lively discussion on estimates on Linked! 🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 33,000-plus subscribers. 🎓 Join Stefan in one of his upcoming Professional Scrum training classes! 📈 Join the Anonymous Poll for the Upcoming Free Scrum Master Salary Report 2022. Estimating Leading to Micro-Management; the Legacy of Taylorism Usually, the fear is that once a product or Scrum team starts estimating, the results will be normalized by the management, compared to other teams, and thus hold against them in the long run by establishing mandatory productivity for a Sprint, for example. Moreover, now that the team’s “velocity” has been set, it will be used to compare the team’s performance with other teams in the organization. Misappropriating an internal team metric might also open a path to stack-ranking teams pitching them against each other, leading to a more competitive and less collaborative environment. In other words: estimating work and creating estimates leads straight back to the industrial paradigm thinking of Mr. Taylor and his supporters. Unfortunately, this ideology of the need to protect the organization from its workers—who managers expect to start slacking the moment they are not directly supervised—is incompatible with the idea of solving complex, adaptive problems and becoming a learning organization. (If you like to broaden your understanding of the precursors of Taylor’s “scientific management system,” I recommend reading Caitlin Rosenthal’s “Accounting for Slavery.”) From Estimates to Velocity to Committing to Deadlines “It’s Difficult to Make Predictions, Especially About the Future.” Typically, a line of argumentation to object estimations as a team is as follows: estimates are by definition no precise calculation as no one can predict the future. However, based on previously aggregated data, see velocity, managers and stakeholders use the numbers to push a Scrum team to make commitments on scope and dates of delivery. This way, they ignore essential principles of working in a complex environment, such as self-management of the team or trusting that the team will do its best to create value for the customers. While this line of thought maybe a valid concern, it is rather a sign for the dysfunction of the organization in question than the toxicity of estimates per se. Hence the consequence should not be ditching estimating itself, but addressing the lack of trust that is reflected in such an agile anti-pattern. A successful way to creating trust between management and stakeholders on the one side and Scrum teams on the other side is regularly delivering valuable Increments. Getting to that level of proficiency requires dedication among the team members to understand why they are working on something, what shall be delivered, and how the Developers will technically realize it. This approach starts way before estimating Product Backlog items at the end of the refinement process. On the contrary, it means including all team members in the product discovery process that feeds new work into the Product Backlog. It is about collaboration, inclusion, and giving everyone a voice in the process. If this teamwork approach is the standard, estimating work items is just the final confirmation that all team members are aligned on the why, the what, and the how. (If not, put in more work refining the work item; apparently, team members still have different perceptions of the upcoming work.) Thus, using a simple planning poker session, the team can mitigate the risk of complexity and inherently become better at delivering. And delivering creates trust among stakeholders. In that scenario, no one needs numbers. Therefore, just ditch them. Conclusion Don’t turn a technical procedure—here: creating estimates—into a scapegoat for the dysfunction of an organization. The root cause of the latter is a lack of trust, which you cannot address merely at a team level. Strive for the creation of a holistic, inclusive product creation process instead. Lastly, I am convinced that people will always “estimate,” whether they talk about it or not. Are you estimating your work? Please share your learnings with us in the comments. 📖 Related Posts Scrum First Principles — How to Elon Musk the Scrum Guide Three Essential Agile Failure Patterns in 7:31 Minutes—Making Your Scrum Work #12 The Meta-Retrospective — How To Get Customers and Stakeholders Onboard Download the Scrum Anti-Patterns Guide for free. ✋ Do Not Miss Out and Learn about Estimates: Join the 10,000-plus Strong ‘Hands-on Agile’ Slack Team I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world. If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

This workshop was delivered on 16th September 2021 and focused on introducing the core concepts of the Sprint Review and its empirical nature. I used a combination of Liberating Structures, Microsoft Teams, and Mural to deliver an interactive session. This session went really well however we had some technical issues on the live stream! Participant feedback was awesome, and we have fixed the audio and re-released the video which is inline below. Topic(s): Agility Audience: Teams, Scrum Masters, Practitioners League of Extraordinary Lean-Agile Practitioners CommunityThe league of extraordinary lean-agile practitioners is a group of peers and seasoned practitioners that continuously learn, share emergent practices, and discuss topics with courage, commitment, focus, respect, & openness! Join The League Introduction to Sprint Reviews [Review] Product Vision \ Goal: Demonstrate the viability and drive interest of live virtual delivery of content as a primary and premier method to share ideas and content. Iteration Summery For this fourth session, my goal was to build on the technology in use and become more proficient. Since we are not using Mighty Networks folks need to RSVP before they can see the join link. Maybe does not count as going… change your RSVP and the join link will be displayed. For some unknown reason we had audio during the intro but not during the stream. I followed the same set-up after the events and everything worked as expected. I feel like it was a glitch as when I or others were speaking “OBS” on my laptop was picking it up, it was just not transmitting. Another check for the DOR before the session. As usual with live stream issues, I was focusing on the people who were participating and did not have time to try to fix it on the fly. I used the Microsoft Teams recording to fix it in Post. Delivery I believe that we met the goal and the feedback was very positive ( Other than those that could not get in). I was very happy with all of the technology used. Feedback There was no negative feedback for this session, however, we did not get to fill out the feedback wall. I was frustrated that the audio was not working and I did not have the time to fix it while I was focused on my participants. As part of the changes in technology, we will be using Lean-Agile Community from naked Agility for events going forward. Folks can join and RSVP just like Meetup. Provide Aditional Anonymous Feedback: https://forms.office.com/r/pdNhe45MVH Introduction to Sprint Reviews [Retrospective] The big retrospective item is the issue with the voice on the live stream. The learning point is not to make an assumption that just because the music is working that the voice is too. Checking both is a good idea. Retrospective outcome: more of the same… build on quality. Other Workshops While these sessions are time-limited we expect to have many free sessions over time. If there are none currently you can contact us for private options. Introduction to Agile Leadership 30 Sep, 2021 | 16:00-17:30 | Europe [ BST ] Workshop Introductory 90 Minutes | Free Register more...

This workshop was delivered on 2nd September 2021 and focused on introducing the core concepts of Kanban & Flow.

 In this video I provide visualisation what the "increment" in Scrum means which hopefully can provide better understanding for people those of you who are new to Scrum.