Sprint Planning Meeting – The Basics

Note: I wrote a similar but different blog post on this same subject later.  This one says some useful things that one does not, and vice versa.  Might challenge your mind usefully to compare and contrast.  See here.

At the beginning of each sprint is a Sprint Planning Meeting (SPM).

Minor point: The SPM is inside the sprint time-box.  It starts the sprint.

The Sprint has real meaning.  Typically the Sprint is a time-box in which the Team will make significant progress in building a releasable product.  Typically, it will take 2 or 10 sprints to build a releasable product. (Not always the case, but we think fairly typical.)  The work of the Sprint, the progress of the Sprint, will be building ‘working product.’  To use Ken Schwaber’s phrase, by the end of the sprint, the stories will become potentially ship-able product increment.

The other wording is ‘working product.’  During the sprint some parts of  the product (that is, the stories selected) will be built, tested, and ‘done’, as defined by a good ‘definition of done.’  This would include all bugs being fixed.  Maybe better to say: all known bugs that relate to a specific story (mini-feature) built during the sprint must be fixed, if that story is to be considered done.

The whole Scrum Team and the business stakeholders come to the SPM.  I imagine the whole team to be 7 people, and that includes the PO and SM. I imagine the Team has 4 people identified and assigned as ‘business stakeholders.’  BSHs are the (4) people who will regularly come to the Sprint Planning Meeting and the Sprint Review, and give the Team independent feedback about the progress and about the details of each story.  These business stakeholders (BSHs) are chickens, not pigs, although they play an important role.

The SPM can be said to have two parts:

(a) Agreeing on the Stories.

This is where the Team agrees to take on some stories of the Sprint.  Specifically, the Implementers pull the stories into the Sprint.  They volunteer.  The recommended rule is that the stories represent the velocity of the prior sprint (Yesterday’s Weather pattern) (unless there is a compelling reason to believe the velocity in the prior sprint is not representative of the true velocity).  Actually, we now mainly recommend the average velocity over the prior 3 sprints.

We typically recommend that these stories be small enough, so that it takes 8 or more small (roughly equal in size) stories to equal the velocity of the Team.

The BSHs must do their best to add or change any information the Team needs to build the stories correctly.  Any failure reduces the productivity of the Team.

At the conclusion of this portion, the business stakeholders can leave.  For a 2 week Sprint this part would usually last less than 1 hour, maybe 30 or 45 minutes.

(b) Agreeing on the Tasks.

In this portion of the SPM, the Implementers identify (volunteers for) their own tasks.  The tasks need to be small.  The recommendation is that they are about 2 hours mostly.  In any case, between 1-6 hours, because they need to be useful in tracking real progress each day (eg, in the Daily Scrum).

Technical issues: Now that the stories are clear, there may be question about how to attack the stories in a technical way.  These might be called architectural or design issues.  These need to be discussed, although major issues should have been discussed prior to the Sprint.  Any thing that would have a notable impact on the story points should have been discussed or resolved earlier.  (This will not always be the case, but professional teams will do a good job in this area.)

Back to the Tasks.  At first the team is terrible at breaking work into small pieces, but soon they learn.

I recommend that each task include a description, initials (of the person currently volunteering for and likely do the work), and an estimate (in hours, for beginning teams).

NB. Any task can be re-assigned to a different person at any moment, if it makes sense.  In general, people are volunteering for tasks; that is the attitude.  And people expect tasks to be re-assigned and re-estimated during the sprint, whenever appropriate.

A key principle: The whole Team is responsible for success.  So, for example, every Implementer is responsible to help any other Implementer with his or her tasks.  This means that each person is, in some sense, responsible or potentially responsible for every task.  So, each Doer must read every task.  And evaluate whether he or she thinks the Team can do all of them in this 2 week timebox.  If there is any slippage, the Team will fail.  And everyone is about Team success (in the Sprint, for the moment).

So, everyone in the Team should also look at the whole plan (the whole Sprint Backlog…stories and tasks) and improve it, as a Team. Anyone can propose improvements to anything. Reassigning tasks, balancing the workload, the hours are estimated too high or too low, tasks are missing, or not necessary.  They all (the Team) are responsible for a good plan for the Sprint.

It bears repeating that the whole team is responsible for success.  Not just in the Sprint, but overall.  Saying ‘I did what I was told to do’ is not enough.  Only real success is meaningful.  The Team are self-managing, self-organizing and self-directing.  It is not a ‘game’ (in the false sense), it is about winning together as a Team.  In addition, it is about really satisfying the customers.

(c) The final part is ‘commitment’.

Well, in the recent Scrum Guide it is not called commitment.

Why?  Because too many managers were thinking this means guarantee.  And ‘forcing’ people to guarantee the future is silly.  Evaluating whether they did a good job (in the past) is useful; but forcing people to work ‘all hours’ to ‘guarantee’ that X amount of work is completed in the Sprint is foolish. Working extra hours does not help.

These managers are right in some respects.  When the Team commits, they should be confident they will fulfill the plan.  Usually that means they will end up being reliable 70-80% of the time. (You can argue what the range should be, and it varies depending on the type of work and the situation.)  So, it is not a meaningless commitment.  But it is also not a guarantee.

The team needs to learn how to become more reliable.  For reliability,  we are talking about reliable for one Sprint at a time.  Reliable for one Sprint means completing all  the stories committed to in that SPM.  But, good teams can only be reliable to some degree (eg, 70-80% of the Sprints) – because innovation work can only be so reliable, and innovation work is inherently surprising.  And, the Team should also exceed their forecast about as often as under-shooting their forecast.  So, longer term they are really quite reliable on average over X (10? 20?) sprints.

(Note: The Team and especially the ScrumMaster are actively trying to increase the velocity.)

Now they have a good plan.  Now they are well positioned to execute well and to succeed.

“First we build trust.”  In this act of commiting and then reliably fulfilling the commitment, trust is built.  Trust between business and technology.  Trust and confidence within the Team.  Trust between the Doers and the PO.  Etc.  Very useful.  You build a Team one sprint at a time.

***

By far I did not explain everything, but the above description gives some useful reminders.

Helpful?

What are some important things I left out?

 

« « Do we really believe in autonomy at work? || Impediments: Orlando May 2015 » »