There is always a discussion during sprint planning sessions about requirements and design, what and how and etc. It seems to be that difference between WHAT and HOW is not always clear for team members and as my experience shows require exact definition within team. By the way, I assume that it might differ from team to team, due to: team experience, type of specialists within a team, level of product owner input and etc.
I noticed following problems due to different understanding of these (WHAT, HOW) terms, which of course lead to failed sprints (and we don’t want such things to happen, do we?:) ):
1. Product owner and Team have different view regarding sprint input
2. Different understanding of “scope creep” definition – f.ex. If column was forgotten in grid. Is it scope creep and should be moved to next sprint? Or is it just “forgotten” task? I understand that you might answer it depends, but the question remains and might lead to very hot discussions.
Note: These questions should arise and addressed during sprint retrospectives, but these just sometimes don’t. Please refer to post script section where sprint planning meeting is defined by the Scrum book.
In order to avoid problems discribed above I always try to detail WHAT definition in the following manner:
1. Business, market and/or users needs. These things can be measured by return of investment and other metrics that make sense in a specific case. For example, we will gain 10 customers in some country market if we are integrated with billing system X. In other words I call this part WHY, which helps team members to understand the actual value we are planning to introduce.
2. Some initial analysis by product owner (or his analytics team) helps to introduce product requirements (or software solution) – actual explanation of WHAT needs to be done within the solution/system/product scope. This section explains the actual goal for the team, the results to be presented at sprint review – it can include mandatory data to be displayed, minimal actions to be performed.
Regarding HOW definition, I expect following from the team:
1. After business goals and actual results are understood, team is ready to start working on high level DESIGN of the implementation.
2. In parallel or after making the design team can move to TASKs identification.
In my opinion all details like which columns should be displayed and which not, how the buttons will appear and etc should be in team’s responsibility and should be included in HOW definition. I intend to call these kinds of “requirements” implementation details rather than product/project requirements.
I have only one strict rule – implementation details can be managed easily by the team (added, changed, removed) unless these actions don’t break WHAT definition of the specific requirements. In other words implementation details should be the first in the line for tradeoffs and should never be treated as scope creep in case if main goal can be successfully achieved.
Summarizing everything above - clarified definition of WHAT and HOW terms help product owner prepare better input into sprint due following reasons:
1. Level of business, feature requirements detalization is defined within team.
2. Better understanding what scope creep is and what “forgotten” task is.
3. Better sprint goal definition and understanding, which automatically leads to better spring reviews (or results acceptance)
P.S. inspired by this post and problems in daily work 🙂
P.S.S. Sprint Planning by the Book
There are two parts to the Sprint Planning Meeting: the “What?” part and the “How?” part. Some Scrum Teams combine the two. In the first part, the Scrum Team addresses the question of “What?” Here, the Product Owner presents the top priority Product Backlog to the Team. They work together to figure out what functionality is to be developed during the next Sprint. The input to this meeting is the Product Backlog, the latest increment of product, the capacity of the Team, and past performance of the Team. The amount of backlog the Team selects is solely up to the Team. Only the Team can assess what it can accomplish over the upcoming Sprint.
Having selected the Product Backlog, a Sprint Goal is crafted. The Sprint Goal is an objective that will be met through the implementation of the Product Backlog. This is a statement that provides guidance to the Team on why it is building the increment. The Sprint Goal is a subset of the release goal.
The reason for having a Sprint Goal is to give the Team some wiggle room regarding the functionality. For example, the goal for the above Sprint could also be: “Automate the client account modification functionality through a secure, recoverable transaction middleware capability.” As the Team works, it keeps this goal in mind. In order to satisfy the goal, it implements the functionality and technology. If the work turns out to be harder than the Team had expected, then the Team collaborates with the Product Owner and only partially implement the functionality.
In the second part of the Sprint Planning Meeting, the Team addresses the question of “How?” During the second four hours of the Sprint Planning Meeting, the Team figures out how it will turn the Product Backlog selected during Sprint Planning Meeting (What) into a done increment. The Team usually starts by designing the work. While designing, the Team identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed so they can be done in less than one day. This task list is called the Sprint Backlog. The Team self-organizes to assign and undertake the work in the Sprint Backlog, either during the Sprint Planning meeting or just-in-time during the Sprint.