Tuesday, April 23, 2013

Scrum tales - Part 14 - Spike goals

Almost all teams currently sprinting have encountered predictable work they can plan ahead but with a twist: work cannot be estimated until the work itself starts which defies a Scrum principle that all sprints must be time-boxed and that all work should be estimated during sprint planning

In a relation to previous post validating addition of research tasks to sprints, let's start using a specific Scrum element going forward whenever a research is required in order to estimate work needed to provide a deliverable - a Spike goal

Spike goal is a PBI that will have a specific deliverable which is not necessarily what Product Owner needs but what the team needs in order to estimate another linked goal that will eventually lead to a concrete deliverable requested by the Product Owner

Each Spike goal must be estimated ahead and time-boxed during sprint planning. The team will only commit to a Spike goal on sprint start. After the Spike is done, related concrete goal will then be estimated and added to the sprint / committed to

Typical workflow involving a Spike goal:
   1) Product Owner requests a deliverable (PBI goal) that is new or unknown to the team and cannot be estimated based on past experience or currently available input data
   2) Team creates a corresponding Spike goal, links it to the base goal and makes sure that the Spike is just above the base goal priority-wise
   3) During Sprint planning, the team time-boxes the Spike to i.e. 2 days in conjunction with Product Owner's approval, and creates corresponding tasks and estimates; team is now committed only to the Spike goal but not yet to the base goal
   4) As soon as the Spike goal is done, team will create tasks for the base goal since now there will be enough input data to estimate tasks leading to the concrete goal deliverable
   5) Sprint is groomed to make room and/or insert now fully estimated base goal and the team commits to deliver the base goal by the end of the sprint

Depending on the Spike goal outcome, it may be clear that the ongoing sprint won't be enough to complete everything needed in order to deliver to the base goal - in such cases it is best to discuss with Product Owner splitting the base goal and committing to deliver at least one part of the goal in the current sprint