Someone may say that planning in Agile is not as important as it is in classic management approaches. But this is a very false assumption. Planning in any of the Agile Frameworks, and for sure in Scrum, is as important as it is in Waterfall. The only and main difference is the horizon for which we plan. In classic management approaches, we are planning the whole project upfront. In Scrum, in details, we are planning only one interaction (or a next 24 hours when it comes to the Daily Scrum, but this is another subject).
Sprint Planning is the event which starts each Sprint. According to Scrum Guide after this event the team should be to the following questions:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
I think there is very important and in fact not so hard to make planning session very effective. Those are the steps I usually try to follow.
Team availability
Before we start planning anything, we need to be aware who from our team will be available during that Sprint. The information that some team member will be forking for 8 days out of 10 days Sprint is better than none. However, it is much better to know the exact days in which this person won’t be available.
How much time we can use to do the actual work
It’s also good to be aware of any “not related events” during the upcoming Sprint. And by “not related events” I men all meetings which are not designed to help us deliver that sprint commitment. For example it can be: grooming session (this is a very important meeting but hardly ever helps to deliver current commitment, it helps to deliver commitment in the upcoming interactions), meeting with CEO to discuss plan of getting people into Mars or winning next customer (which is also very important but not for the current sprint) or any other company meeting for that matter (e.g.: foosball tournament).
I might go and agree that as “not related meeting” we should treat only events which are not reoccurring. Meeting with CEO or Grooming Sessions might happen every Sprint, therefore there is no bearing on the team’s velocity.
Agree on the scope
This part is quite easy if you have Product Backlog organized (most important items are on the top, blockers are above items they block, etc), PBIs are sized (estimated) and you have historical information about team’s velocity (irrelevant is the way you measure it). Based on those 3 and information that we just gathered (team availability & not related events) we are picking up items from the top of the Product Backlog building our Sprint Backlog.
In case the team is not familiar with PBIs on the top of the backlog and/or they are not sized team need to spend more time to get that done during Sprint Planning. Continue without it might cause that plan created for that sprint would be inappropriate and hard to follow.
Review high level dependencies
This is directly related to the previous step. We need to check if our Sprint Backlog does not have any dependencies which might cause a problem with delivering Sprint. And if we do, we need to be aware of this risk so we can handle it properly, so we can plan mitigation steps. It’s worthless to take into the Sprint something the team knows they can
And by the dependencies, I mean also internal and external. For example, in Sprint Backlog, we have two items. The first one says “User is able to book an appointment” and second says “Owner is able to approve a booking”. In that case, we have an internal dependency as the team is not able to deliver the second item until the first one is done (we are not able to approve booking that has not been created). An example of external dependency will be a case in which one team has the first item and another team has the second item. The other example of the external dependency would be a case in which we need to deploy an application into the server which does not exist or to which none of the team members has access.
Short note. In most cases (not in all) it is better to remove dependent Sprint Backlog Item from the Sprint Backlog (and exchange with another from Product Backlog) then create a plan with a heightened risk of failure.
Brake down Sprint Backlog Items
Sprint Planning is also a time to break down each Sprint Backlog Item into smaller pieces (I call it tasking). Breaking down not only provides detailed information on what needs to be done. It helps to see the progress as the Sprint goes on. In addition, a proper break down (with dependencies indications) allows planning how many people and when can be involved in a work.
Plan how we are going to deliver
From my perspective, it is not enough to plan what the team is going to deliver at the end of the Sprint. If that is the only plan we have it is hard to monitor the progress and react to all unexpected events (unexpected sick leave,
The last part of the Sprint Planing should provide more detailed information. The information in which order Sprint Backlog Items are going to be delivered and when each of them will be delivered (done, tested and ). And saying all of them will be delivered the last day of the sprint make a plan created during Sprint Planning a high risk from the beginning.
Teams I work with for this part of the Sprint Planning are using Gantt Chart method. Created Gantt Chart is used on Daily Scrum (adjusted if necessary) to monitor the progress of the work.