If your backlog is not refined then you are doing it wrong

Most Scrum Teams that I encounter don’t do refinement of their Product Backlog and try to work on things that they don’t understand correctly. However, if you get to the Sprint Planning event and your backlog is not ready, then you are doing it wrong. If what you build is not of good quality then […]

The Product Goal is a commitment for the Product Backlog

Scrum-Framework-Product-Goal

In the 2020 Scrum Guide Ken and Jeff introduces the idea of the Product Goal. The Product Goal is a commitment to ensure transparency and focus against progress. The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is […]

I do continuous deliver, why should I Sprint?

Martin Hinshelwood·FollowPublished innaked Agility from Martin Hinshelwood·3 min read·May 17, 2017–Many folks believe that a Sprint is an arbitrary length of time in which you create and release software. They look at their continuous delivery pipeline and say to themselves; “Why would I limit myself to shipping only once every two weeks?”To that I say: “Where in the Scrum Guide does it say that you can’t release every day?”You will not find it, I know as I have looked. I work with many teams that release software on a continuous delivery model of everything from a few hours, to a few days, and often on-demand. Can you say that they are not doing Scrum? Of course not.So why would you want a Sprint at all?A Sprint enshrines your empirical process by providing a maximum delivery cadenceIt increases communication and alignmentIt Adds some predictability to the unpredictable nature of software by evening the batch sizes.A Sprint is a container for planning!As far as the Scrum Guide is concerned you must deliver working software at least every 30 days, but there is nothing to stop you doing it more frequently than that. Indeed continuous delivery and Scrum go together quite well in my experience.A Sprint enshrines inspect and adapt by containing your other feedback loops:Sprint Planning — Inspect the Backlog and Adapt the plan for the next SprintDaily Scrum — Inspect progress and adapt the plan for the next 24hours.Sprint Review — Inspect the Increment and adapt the BacklogSprint Retrospective — Inspect the Sprint and adapt the process.Without a Sprint when would you bring all this together? The Sprint makes the effort required to pull your work together and create a Done increment of software mandatory. It is absolutely crucial to understand that if you don’t at least have working software that meets your definition of done by the end of the Sprint then you are not doing Scrum.If you are an awesome disciplined team then by all means do something that looks a little more like Kanban, but if you don’t have the discipline to follow the rules of Scrum, how would you expect Kanban to work.Communication & AlignmentAn additional benefit of Sprinting is that it gives a cadence that your management, and other dependant teams, can follow easily. If you are coordinating work, then having a common frame of reference, Sprint 231, will aid in communication.Creates PredictabilitySoftware is inherently unpredictable. The standard deviation between the amount of work required for seemingly similar tasks is so big that it is very difficult to gain predictability. A Sprint creates an artificial batch of a fixed size (or at least less varied) with a time boxed Sprint so that you can create that cadence of predictability.ConclusionA Sprint is a container for planning rather than releasing and while Scrum requires that you have a working increment of software at least every Sprint, there is nothing to stop you doing it more often. Indeed the recommendation from Scrum.org is that you not only ship your software at least every 30 days, you should endeavour to do so more often.Scrum.org recently changed its mantra from “Improve the profession of software development” to “Improve the profession of software delivery” to start to enshrine the idea that delivery, to your customers, is no longer optional to get significant actionable feedback that you can reflect on.In short, while the Scrum Guide does not explicitly state it, it is no longer optional to ship your software to production at least every 30 days if you want to stay competitive and build the software that your users deserve.Who is naked Agility Limited — Martin HinshelwoodMartin Hinshelwood is the Founder/CEO of naked Agility Limited and has been their Principal Consultant and Trainer on DevOps & Agility for four years. Martin is a Professional Scrum Trainer, Microsoft MVP: Visual Studio and Development Technologies, and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010 and has been delivering software since 2000. Martin is available for private consulting and training worldwide and has many public classes across the globe.Originally published at nkdagility.com on May 17, 2017.Martin Hinshelwoodinnaked Agility from Martin HinshelwoodGetting started with a modern source control system and DevOpsThere are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code…8 min read·Nov 10, 2017–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodHow do you handle conflict in a Scrum Team?As part of the Scrum.org webinar “Ask a Professional Scrum Trainer — Martin Hinshelwood — Answering Your Most Pressing Scrum Questions” I…3 min read·Oct 7, 2019–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodWhat my father taught me about Evidence-based Management (34 years before it was invented!)A few weeks ago I headed out to the Scrum.org offices in Boston to participate in training to hone my skills as an Evidence-based…7 min read·Mar 20, 2014–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodThe Dumpster fire of SAFe!SAFe has done irreparable damage to many companies like Volvo & Fitbit. Do not take their case studies at face value!2 min read·Jun 25, 2022–Kevin CooperLean vs Agile — The Alchemy of DevelopmentUnderstanding Lean and Agile: A Comparative Overview9 min read·Sep 21, 2023–1Ahmed BadranHow to Use Jira Product Discovery to Manage Ideas, Build Roadmaps, and Prioritize What to Build…An Example of Using Jira Product Discovery Custom views to build RICE Framework Board.5 min read·Sep 20, 2023–Wilson GovindjiinAgile InsiderTesters have no place in a Scrum team…Know how to succeed with testers in a Scrum team·6 min read·Jan 26, 2024–1Luke PivacinAgile | AdaptHow to Write and Manage Dependencies in Agile ProjectsA how-to guide on creating and managing dependencies.·7 min read·Dec 26, 2023–1Ameer OmidvarinBootcampApple’s all new design languageMy name is Ameer, currently the designer of Sigma. I’ve been in love with design since i was a kid. It was just my thing. To make things…4 min read·Feb 14, 2024–28Jessyvictany5 Best Alternatives to AgileLearn more about 5 different alternatives to Agile development.5 min read·Oct 6, 2023–1

The fallacy of the rejected backlog item

Martin Hinshelwood·FollowPublished innaked Agility from Martin Hinshelwood·6 min read·Dec 13, 2017–There is a frustrating misunderstanding of reality when one thinks that the Product Owner can reject a single story at the Sprint Review. This is the fallacy of the rejected backlog item and the misguided belief that this backlog item can just be left out of this delivery. That backlog item that was chosen by the Development Team at the Sprint Planning event to help them achieve the Sprint Goal. The Sprint Goal that created focus and has the entire Development Team working in the same area of the codebase.The fallacy is that without this single Backlog Item, one of many, the code will still function as intended.TL;DR;Since the Development Team is held accountable for quality, but not quantity, and they sure cant be held accountable for meeting expectation.DONE — If in the pursuit of the Sprint Goal the output of the Sprint is a DONE Increment of working software then the Development Team did everything they were required to do. Any gap between what was delivered and expectation is merely a learning opportunity. At the Sprint Review, the Scrum Team investigates this gap and updates the Product Backlog to reflect what is now needed next.NOT DONE — If the Development Team is not “Done” at the end of the Sprint then there are some consequences: An increase in Technical Debt that is going to make future work slower; Removing the option for the Product Owner to release the product if they so choose; With undone work, you have to fix it next Sprint and thus interfere with the next Sprint Goal and the Product Owners delivery expectations; Remove any chance of predictability for future sprints until the undone work is under control.But if its DONE. There is no rejection of the Backlog Item there is only feedback. There is just a learning opportunity that can be used to reduce the expectations gap for future Sprints. Reflect on that during the Sprint Review, engage with Stakeholders to better understand both their intent and their expectations.Empirical process control is not about doing everything correctly, it’s about transparency, inspecting, and adapting.Oh, the Product Owner can deny the assertion of the Development Team that they have completed it and had them re-estimate it and stick it back on the backlog. They can decide to postpone deployment until the next Sprint. They can even choose to reject the entire Sprint and lose all of the work done in that Sprint. My point is that it is neither physically nor technically possible to remove a single PBI from a Sprint without incurring significant rework.A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. –Scrum Guide — Sprint ReviewThe Scrum Guide 2017 mentions nothing of rejecting anything at the Sprint Review.This is the reality of product development that gets in the way of the idea of the rejected backlog item. The software that we are producing is complex. If we are creating a Sprint Goal and selecting backlog items that help us achieve that Sprint Goal then they are probably inter-related. These inter-related items will likely build on and reference each other’s functionality. If we then decide to rip one of the nodes out of this complex web of classes and methods, then we are increasing risk, and we are also unlikely to have working software at the end of the Sprint. Oh, I am sure that there are exceptions, but it will take time to remove no matter how good the team’s engineering practices.Just to be clear, this is not about Done. I expect every team to produce work that meets whatever definition of done that they have agreed with the Product Owner. If the Development Team calls Done when they are not then that is a wholly separate problem… because Professional Scrum Teams build software that works.Rejecting a Backlog Item is missing the pointNot only that but you may be missing the whole point of the Sprint Review. It is not about acceptance or rejection of the increment by the Product Owner, but instead, it is about discovery and understanding between the Product Owner, the Development Team, and Stakeholders. It is one of the keys inspect and adapts points for the Product Backlog. The Product Owner, being human, perhaps had a picture of what they wanted in their head that does not match what the Development team has produced. In this case, the Development Team need to work with the Product Owner to update the backlog with the changes that now need to make it that which the Product Owner envisaged. So it meets “done”, it meets the acceptance criteria, and it is still not what the Product Owner wanted. Is this the Development Teams fault? Of course not… it is a learning point, and inspect and adaption of understanding between the Product Owner and the Development Team. The Product Owner learned how the Development Team interprets their words and the Development Team learned something about the Product Owners intent. This is intensely valuable learning for the Scrum Team as a whole.There are only three actions open to the Product Owner at the Sprint Review:Update the Product Backlog to reflect what we now need to do to achieve the visionChoose to ship the current increment or notChoose to end the project or continueMaking it easier with feature flags or togglesAll of that being said it is the job of the Development Team to make things as flexible for the Product Owner as possible. They should implement what capabilities that they need into each increment to make it possible for them to turn a new feature off and still ship. This will not only make the Product Owner happy; it will get the newly built features in front of the Stakeholders as quickly as possible for feedback.There are a few things that can make this as easy as possible:Communication — Good communication between the Product Owner and the Development Team can help alleviate these sorts of issues. However, continued interfering in the Development Team by the Product Owner will make it harder to deliver what was estimated. The Development Team should deliver their understanding of what the Product Owner presented to them at the Sprint Planning meeting while collaborating where timely and appropriate.INVEST– Making sure that your PBI’s are all following the INVEST [Independent | Negotiable | Valuable | Estimable | Sized appropriately | Testable] model. If you follow this guide, then you can minimise any misunderstanding between the Product Owner and the Development Team.Feature Flippers/toggles/flags — The single most valuable thing in your developer’s arsenal is the ability to turn the things that you are adding on and off at will. This should be applied both to a feature and the multiple layers of that feature that are added to each pass delivering PBI’s. You may think of each PBI’s as requiring a switch to be able to turn it on or off. It is usually not perfect as there are some things that are iterations of the same feature. More advanced implementations may allow you to enable or disable features by account or user.If you can do all of these things as they will all add value by making it easier to give the Product Owner flexibility.Who is naked Agility Limited — Martin HinshelwoodMartin Hinshelwood believes that every company deserves high-quality software delivered on a regular cadence that meets its customer’s needs. His goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals. Martin is the Founder/CEO of naked Agility Limited and is both a Professional Scrum Trainer and a Microsoft MVP: Visual Studio and Development Technologies. He has been delivering software since 2000 and has been Consulting, Coaching, and Training in DevOps & Agility with Visual Studio, Azure, Team Services, and Scrum since 2010. You can reach Martin on hello@nkdagility.com.Originally published at nkdagility.com on December 13, 2017.Martin Hinshelwoodinnaked Agility from Martin HinshelwoodGetting started with a modern source control system and DevOpsThere are a number of things that you have to think about when selecting a modern source control system. Some of that is purely about code…8 min read·Nov 10, 2017–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodHow do you handle conflict in a Scrum Team?As part of the Scrum.org webinar “Ask a Professional Scrum Trainer — Martin Hinshelwood — Answering Your Most Pressing Scrum Questions” I…3 min read·Oct 7, 2019–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodWhat my father taught me about Evidence-based Management (34 years before it was invented!)A few weeks ago I headed out to the Scrum.org offices in Boston to participate in training to hone my skills as an Evidence-based…7 min read·Mar 20, 2014–Martin Hinshelwoodinnaked Agility from Martin HinshelwoodThe Dumpster fire of SAFe!SAFe has done irreparable damage to many companies like Volvo & Fitbit. Do not take their case studies at face value!2 min read·Jun 25, 2022–Ameer OmidvarinBootcampApple’s all new design languageMy name is Ameer, currently the designer of Sigma. I’ve been in love with design since i was a kid. It was just my thing. To make things…4 min read·Feb 14, 2024–28Kevin CooperLean vs Agile — The Alchemy of DevelopmentUnderstanding Lean and Agile: A Comparative Overview9 min read·Sep 21, 2023–1Matej LatininUX Collective90% of designers are unhirable?Or why your cookie-cutter portfolio doesn’t cut it and how to fix it13 min read·Mar 6, 2024–45Vineeta BansalProduct Managers: Metrics in Machine Learning 101In the ever-evolving landscape of machine learning, understanding how to evaluate model performance is akin to navigating a dense forest…3 min read·4 days ago–Karolina KozmanaCommon side effects of not drinkingBy rejecting alcohol, you reject something very human, an extra limb that we have collectively grown to deal with reality and with each…10 min read·Jan 21, 2024–658Ahmed BadranHow to Use Jira Product Discovery to Manage Ideas, Build Roadmaps, and Prioritize What to Build…An Example of Using Jira Product Discovery Custom views to build RICE Framework Board.5 min read·Sep 20, 2023–

The fallacy of the rejected backlog item

To my understanding there is a frustrating misunderstanding of reality when one thinks that the Product Owner can reject a single story at the Sprint Review. This is the fallacy of the rejected backlog item.

Can the Definition of Done change per Sprint?

I was asked this question today and I think there is a clear answer, however it may change depending on the context of the question. “During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with […]

How do you incorporate a Design Sprint in Scrum?

As part of the Scrum.org webinar “Ask a Professional Scrum Trainer – Martin Hinshelwood – Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those […]

Work can flow across the Sprint boundary

There is nothing in the Scrum Guide that says that you can’t have workflow across the Sprint boundary. I’m going to suggest that not only can you, but you should as long as you don’t endanger the Sprint Goal. UPDATE: To find out how to allow work to flow across the Sprint boundary you can […]

I do continuous deliver, why should I Sprint?

Many folks believe that a Sprint is an arbitrary length of time in which you create and release software. They look at their continuous delivery pipeline and say to themselves; “Why would I limit myself to shipping only once every two weeks?” UPDATE: Scrum.org just posted my Scrum Tapas – Scrum and Continuous Delivery which […]