Scrum Events : Sprint Planning

Agile does not mean no planning. Agile means intense planning - for short time horizons.

The purpose of the sprint planning meeting is to do the intense planning that sets the team up for an effective and efficient sprint.

Sprint planning is the very first activity in every sprint.  In the Sprint Planning meeting we identify the volume of work for the sprint (the commit - or forecast) and we create most of the knowable tasks to deliver it (the Sprint Plan).

Maximum duration is a four hour time-box for a two-week sprint (eight hours for a one-month sprint); New teams may find it had to spend that long in planning, and as teams gain mastery the value in a detailed planning session becomes evident, and teams are more willing (and eager) to put in the time required to ensure they can have a smooth sprint.

Sprint planning is where the team makes sure that the FLOW of work in the sprint can move effectively through the process (The devOps 1st way).

Sprint planning is also the meeting where we ensure that we control work in progress (WIP) , because we know that too much WIP leads to slower outputs, lower quality and burnout.

We control too much WIP by ensuring that only the people doing the work (i.e. the development team) can decide how much work will be pulled into the sprint

Only the Product Owner can decide what work the development team can pull into a sprint, because it is the product owners responsibility to make sure that only work of the highest value is committed to.

The development team must pull from the top of the product backlog, only, they cannot cherry pick what work to do.

Checklist

 

 Priority | Product Manager has confirmed that the Product Backlog is prioritized the way they want it
 READY | Product Manager has confirmed that there are sufficient Product Backlog items READY to carry out at least one sprint
 GOAL | Scrum Team have discussed and agree the draft Goal for the Sprint
 On-Call | Product Owner has left if they wish to but remains on call for questions
 Capacity |  Development Team identifies their capacity for the Sprint
 Planning | READY-Check |  Development Team pulls the First Item and confirms it is READY
 Planning | Tasking out |  Development Team identifies tasks required to deliver the current item
 Planning | TaskSize |  Tasks are decomposed to one person-day or less
 Planning | Item Commit |  After tasking out, the Development Team commits (or not) to accepting the item into the sprint
 Repeat |  Planning process is repeated until Development team indicates capacity is filled
 CONFIRM |  Sprint Goal is re-negotiated or confirmed with Product Owner
 COMMIT |  Scrum team commits to the Sprint Backlog, Plan and Goal