Sprint Planning in a SCRUM team is an essential piece of the jigsaw. Allowing teams to collectively understand, detail and size stories provides (or at least aims to add) predictability to sprint delivery.

Detailing the tasks, integrations, need for stubs and level of acceptance for each story allows us to determine what ‘Done’ looks like. Which brings us to the title of this post “when 2 + 2 doesn’t equal 4”, by this I refer to the concept of Story Points.

In my experience, one of the key decisions to be made by the SCRUM team at Sprint 0 is what a story point looks like and refers to. Agreeing with your stakeholders upfront what that size indicator means, will avoid confusion during sprint planning sessions.

Some Stakeholders will see 2 people available to do two; 8 hour days as 4 days or 32 hours of effort. Then as soon as you enter the sprint, those same stakeholders will want a 2 hour workshop, instantly reducing capacity of our 2 team members, which will pressure the sprint and create (potentially) the perception of failure.

Adopting the point system, whether that be basing an individuals realistic daily capacity as 2, 4 or 6 hours is irrelevant, the importance is to pave the way for successful sprint completion. Providing a measure of effort, that stakeholders can refer to, understand, and gain predictability is key. Allowing sufficient time to plan ahead to keep the backlog machine working.

Except for our Stakeholder, I have made no reference to specific roles in our SCRUM team, the point system should be applied to all members of that team, each story will have a number of tasks, whether that is for a ‘BA’ to define a set of business rules, a ‘QA’ to implement a set of acceptance tests or a developer to write some code, all tasks are important to that story and working towards an agreed definition of ‘Done’, adopting a standard measure, at least allows a collaborative understanding of the task in hand……

%d bloggers like this: