Anand Pandey

Welcome to Scrum Sutra – a blog series where I shall share a 3-min overview of each element of Scrum and how it connects with the other elements in the bead to form Scrum Sutra.

Welcome to Scrum Sutra – a blog series where I shall share a 3-min overview of each element of Scrum and how it connects with the other elements in the bead to form Scrum Sutra.

What is an Increment and how does it connect with the other elements of Scrum?

The new Scrum Guide 2020 mentions Scrum is founded on empiricism and lean thinking. In this post, Anand Pandey dives into how to identify waste.

The Scrum Guide defines Sprint Goal as the single objective for the Sprint, is a commitment by the Developers, and is part of the Sprint Backlog. While many agree the importance of it, equally struggle in creating a good Sprint Goal. So let me share with you how I helped a Scrum Team write a good Sprint Goal. While the Scrum Team had a good Definition of Done in place, they didn’t have a Sprint Goal. Actually, they had it, but it was same as “Completing all Sprint Backlog items”. When I enquired, I got a question I somehow expected — “We have our Sprint Backlog and we have to deliver all the items, so isn’t that supposed to be our Sprint Goal?” I am sure few of you must have experienced this question sometime in your journey. Saving your time from that conversation, and the explanation part on Sprint Goal, let me take you to the next Sprint Planning event. And I could see the same pattern getting repeated. Smith, the Product Owner presenting the Product Backlog, and Developers pulling Product Backlog Items into Sprint Backlog and crafting similar Sprint Goal — “Getting all PBIs done”. I could relate the Sprint Goal as manifestation of Habit — 2 “Begin with End in Mind” in a much inspiring book “The 7 Habits Of Highly Effective People” by Stephen Covey. Taking that inspiration, I asked the Scrum Team to frame in one sentence what does the end goal of this Sprint look like, the sentence which they would put in the Sprint Review invite to stakeholders and which will excite them to participate. The sentence that will give them a true purpose, and reason to collaborate. Something that will motivate them to come to office every day for the entire Sprint ! The Scrum Team looked at their Sprint Backlog and struggled — they could not find any pattern within the chosen PBIs as all seemed unrelated. Smith showed courage initiating the conversation: Smith: “How do you create a Sprint Goal out of the unrelated set of items?” Anand: “We will come to that question. But for now, let’s take a step back and re-look at our Product Goal.” Smith: “So, our Product Goal is ‘Improve online Customer claim submission from 30% to 60% in 1 year’.” Anand: “Good place to start with. With that as our end target, what else was in your mind when you ordered the Product Backlog?” Smith: “I am worried about the increasingly bad customer satisfaction feedback on our Claim Submission form and I suppose that may have reflected in my ordering of the Product Backlog!” Anand: “And how would this Sprint help in addressing your concern and help us progress toward the Product Goal?” Smith: “If we could do something about the Claim Submission experience!” Scrum Guide: The Product Owner proposes how the product could increase its value and utility in the current Sprint. Now, the Scrum Team has a sense of alignment and they came up with an initial Sprint Goal. Scrum Team: “How does ‘Reducing customer defect’ look like as a Sprint Goal?” Anand: “Looks good! Now, how will we know if we have achieved the Sprint Goal? How can we make it SMART goal?” Scrum Team: “How about putting some numbers to it? Like ‘Reducing customer defect in claim submission form by 20%”? Will this qualify as a good Sprint Goal?” Anand: “That is something for you all to determine. Few pointers from my side though.” · Will the Stakeholders be excited about it and looking forward to join the Sprint Review? · Will it help the Developers remain focused for the Sprint duration? · Will it provide flexibility in what work is needed be done to achieve it? · Will it give a reason for the Developers to collaborate? Scrum Team: “We feel we can tick most of those items for our Sprint Goal. So are we done?” Anand: “Not yet! Given that we have agreed on the Sprint Goal, lets reflect back to our chosen Product Backlog items and see if we want to revisit it based on the newly created Sprint Goal.” Scrum Team: “We could connect quite a lot of Product Backlog items to our Sprint Goal. So, now we see the cohesiveness you were talking about during our initial discussion.” Anand: “Good to know. What else?” Scrum Team: “We could see few Product Backlog items which cannot be linked to the Sprint Goal. What to do about those?” Anand: “While you may have few Product Backlog items which may not be linked to the Sprint Goal, and that is OK. As an example, as part of your commitment to the Technical Debt removal, you may have an item toward that. But if you see a lot of Product Backlog items not having cohesiveness then it s a sign that either your Sprint length is too long, or that there the Product Backlog is not properly aligned with the Product Goal. Let’s hear from Smith and discuss with him on this.” In discussion with Smith, the Developers were able to swap some unrelated Product Backlog items with the ones which would help achieve the Sprint Goal. And for the remaining capacity, Developers pulled in Product Backlog items which will help make product usable. And they considered revisiting their Sprint length. Anand: “Now, I invite you to write your Sprint Goal in a big flip chart paper and put it in a common place where you generally conduct your Daily Scrum. And the very best of luck in your journey toward the Sprint Goal.” I hope you had a good experience reading the above. In conclusion, a good Sprint Goal can help Developers remain focused on the purpose, encourage collaboration, and helps in flexibility on the plan to create a Done Increment by the end of a Sprint.

Welcome to Scrum Sutra — a series where I shall share a 2-min overview of each element of Scrum and how it connects with the other elements in the bead to form Scrum Sutra. Today, I shall talk about Sprint Backlog.

Welcome to Scrum Sutra — a series where I shall share a 2-min overview of each element of Scrum and how it connects with the other elements in the bead to form Scrum Sutra. This bead is about Product Backlog.

Welcome to Scrum Sutra — a series where I shall share a 3-min overview of each element of Scrum and how it connects with the other elements in the bead to form Scrum Sutra. “Successful use of Scrum depends on people becoming proficient in living five values.” — Scrum Guide 2020 Scrum as a framework has no prescribed rule for every interaction and collaboration within and outside the Scrum Team. It is intentionally done to allow individuals and teams to make their own decisions on how they would like to have their interactions, and processes to achieve higher productivity and better value delivery. In order to help the Scrum Team and Stakeholders make that effective decision, the Scrum Guide provides a set of values on which Scrum is based. The Scrum Team and Stakeholders become proficient when they use the Scrum values for every decision they make. And then subject those decisions to empiricism — apply those experimentally, observe the results and draw conclusions. “When your values are clear to you, making decisions becomes easier.” — Roy Disney A great Scrum Team puts every action and decision of theirs to a litmus test: “Will this action move us closer to honoring our Scrum values or further away?” “If we make this decision, will we still be living the Scrum values?” A decision based on the Values may not be the easiest or the most enjoyable at that moment. But that discomfort will pass and what will remain is the internal feeling of rightness for a more fulfilling decision. On the contrary, a decision made based on what is easier now, which will maintain status-quo will leave the team feel tensed. Hence, the Scrum Team need to be courageous to make decisions according to values. “The bitterness of poor quality remains long after the sweetness of low price is forgotten.” — Benjamin Franklin What values the Scrum Team honor show up in the choices they make in their day-to-day interaction and those choices are visible in the behavior they demonstrate. Just walk past a Daily Scrum and you will notice the values they honor just by observing their behavior. As an example, you will see Developers being Respectful to each other’s inputs, being Open to demonstrate progress, Open to feedback, Open to ask for, and offer help, Open to inspect and adapt Sprint Plan toward the Sprint Goal, to be Courageous to hold each other accountable and to discuss impediments. All this to ensure their Commitment and Focus on the Sprint Goal. Sprint Retrospective is a formal opportunity for the Scrum Team to look back over their various interactions and the decisions they’ve made and see where the Scrum values were honored or were ignored. As a Scrum Master this information is very valuable to you for value clarification and to help the team see an elephant in the room. Closing Words There is no specific order for Scrum Values, rather they form a constellation. So, while each Scrum Value has its own unique tone, when played together they create a unique harmony. When a Scrum Team and Stakeholders do not maintain that symphony, the discord can get so disturbing that it can become toxic. An increase in proficiency in living the Scrum values allows for more effective events, more useful artifacts and accountabilities acted out more productively. All these factors foster trust, empirical process control and make the Scrum Team maximize value, reduce waste and manage risk. _________________________________________________________________________________________________________ If you want to learn more about Scrum and gain more insights on the Scrum framework you can visit https://targetagility.com/blogs/

That is the very essence of Empiricism - that there exists no "correct" way of working on a complex situation. And even if it does exist, it is not possible to know it in advance. Hence the entire process should be a series of controlled experiments and data-driven decisions aiming towards the overarching goal.