The language itself has become less normative. Only the Product Owner has the authority to cancel the Sprint. Before it had an entire subsection dedicated to it – now it’s just literally two sentences.Ī Sprint could be cancelled if the Sprint Goal becomes obsolete. The section on cancelling a Sprint in the new Scrum Guide is also much shorter now. Why is that? Primarily, some redundant and complex instructions, as well as questions in Daily Scrum, were dropped. It’s now just 13 pages instead of 19 – a reduction of over 30%. If you are familiar with the previous version of Scrum Guide, you will immediately notice how much smaller Scrum got with the new release. It’s not an exaggeration to say that with the new version of the Scrum Guide, the connection and understanding between Scrum and the Business will be better than ever. It’s an approach mentioned by IIBA in Agile Business Analysis among others.
Again, it’s an answer to the needs of Business Analysis. It protects the product Backlog from becoming a wish-list of tasks that will never be completed. Īnother important aspect of the Why questions is that it forces the PO to implement the analyze to determine what is valuable process before an element can be added to the product Backlog. You can read more about the relationship between business needs and User Stories here. It helps fulfil one of the 7 principles of Agile Business Analysis, that is See the whole.
The Why questions also make it easier for developers to understand the business value of a given task, feature or User Story. You can focus on who it is for, what should be done and what can be achieved with it. Those who write User Stories in order to describe requirements also know that the Why question is an essential part of the description because it helps you understand the benefit to be achieved by the user in the story. It’s been in a way a part of Scrum for years during the process of gathering requirements – a technique known as the 5 Whys. To make the Why question separate seems like a natural step. With Why, the Scrum process and the Sprint Planning is going to be very different. Up till now, the Sprints were more about What, while developers handled the How side of things. The truth is that business analysts have been trying to get the Product Owner (PO) and other Scrum team members to answer the why question for years. The introduction of Product Goal and all the implications of it are a big nod towards the world of business analysis. The three questions of Sprint Planning: Why, What, How? Each one of them has a commitment – for Increment, it’s Definition of Done (DoD) for Sprint Backlog, it’s Sprint Goal and Product Backlog corresponds with Product Goal. They must fulfil (or abandon) one objective before taking on the next.Īdding a Product Goal also takes care of the issue of Scrum Artifacts. The Product Goal is the long-term objective of the Scrum Team. Only once it is completed, you can move to the next one. Just like it is the case with the Sprint Goal, there should only be one Product Goal defined at any given moment. It gives a wider perspective and tells us how much you still need to do to get to the final goal. It allows you to define a bigger goal you want to achieve by completing the smaller goals of the Sprint. Introducing this new goal brings the Scrum Team (more about it later) even closer to the business. Until now, the Scrum Team only got to define one goal – the Sprint Goal. Product GoalĪn entirely new concept introduced in Scrum Guide 2020.