Model Driven Sprint Planning

Most Scrum Teams I encounter as an Agile Coach experience difficulties with the Sprint Planning. I think there are a number of reasons for this, but one of the major reasons is that there seems to be a large misunderstanding about what the Sprint Plan actually is and what it is good for. Scrum simply states that the Sprint Planning is where the Team turns the selected Product Backlog Items into tasks and most Teams seem to do a very backlog item oriented breakdown, i.e. they look at the selected backlog items one at a time and discuss what tasks they need to perform to implement it. A typical task breakdown of a backlog item might look like this:

Some questions that come to my mind are: is this really a plan? When is Code Java done? What happens if defects are found during testing? How does the team collaborate around those activities? Teams that use this form of Sprint planning seem to be living with the misconception that they have to develop things in the order the product owner prioritized the product backlog to ensure that they can remove items from the bottom of they discover that they can’t meet the Sprint Goal. The Sprint Goal in these cases is typically stated as “do the ten top prioritized backlog items” or “develop nn points of backlog items” or even “do as many backlog items as you possibly can”.

So what is the problem with this type of planning then? Well one thing is that it doesn’t promote collaboration or interaction, another is that it is totally devoid of system design and yet another is that it is based on the assumption that the Team will need to remove things.

The solution to this problem starts at the Product Owner and his Release Plan (or road map or whatever you want to call it), it absolutely must contain clear goals! This gives the Team an overview of the evolution of the Product and it enables them to make better design decisions. Next step is to keep the Team close to the product backlog, they need to look at it frequently and work together with the Product Owner to get an understanding of what is to come, why the he wants it and how the Team need to solve the problems they are facing to prepare for the future (careful not to introduce any waste though).

When the Team has had a look at the road map and understand why the backlog items are important to the Product and the Product Owner it is time to prepare for planning, time to create the Model. The Model could be in UML or any other available modeling language or it can simply be a lot of boxes and circles – it doesn’t really matter as long as the team it! It is the blueprint of the Product and guides the Team to what should be done and what the Increment will look like after the sprint. If you don’t have a Model you need to create one, it is important that it represents the product as it looks right now, what level of detail is, again, up to the team.

During Sprint Planning the Team looks at the Model and the selected Product Backlog Items and have a discussion on how the model needs to change in order to meet the Sprint Goal (might be a good idea to have a look at the Robustness Analysis of the Iconix process). When this is done the team identifies the things they need to produce during the Sprint, the Results, and in what order it is most beneficial to develop them and creates the lan. The plan might not be anything else than the annotated Results on the wall in an ordered sequence. The important thing is that the team knows what to do, how to do it and how it will look when it is done and that they have considered the Definition of Done.

The major benefits of the Model Driven Sprint Planning are that the design and architecture becomes the business of the entire Team and it promotes knowledge sharing. It also forces the Product Owner to collaborate with the Team to be able to prioritize the Product Backlog in a good way. It also forces the Team to take their commitment seriously since it is more difficult to remove Product Backlog Items mid Sprint to push down the Sprint Burndown Chart, instead they have to use problem solving which is a great team exscercise.