Russell Bateman
December 2016
Let's refine sprint planning.
In part 1, we learned that sprint planning is often done in two gulps. This is because there's too much for developers to accomplish during sprint planning while the product owner and Scrum master sit on their hands. Some of what I'm proposing here isn't properly Scrum, but has proved useful over my decade of Scrum experience. Let's take the two parts one by one.In this part, which can happen anytime before the sprint as needed, we über-groom a list of stories from the backlog. This part can be used to help out the product owner in the case where product ownership is less formal than in bigger companies.
Grooming a backlog means, fundamentally, ensuring
This is crucial to the stories that are to be undertaken in a sprint. Epics are nothing that can be tackled by any development team during any sprint. In fact, epic is arguably not Scrum. It's a useful concept that arose subsequent to Scrum's beginnings. An epic is a major view of product functionality that will likely be broken down into proper stories. There is nothing wrong with an epic in the backlog, but epics cannot be pulled from a backlog to create work for a sprint.
As pointed out in part 1, this is super important. The Agile tool holding the stories is a crucial resource to the whole Scrum effort. What represents a story (in the Agile tool) must have:
In part 1, we plugged story statement, additional detail and acceptance criteria hard.
The lead developer may do this step alone or he may draft help from other developers. This is the bit that takes the most effort. In JIRA, the task break-downs will be subtasks under each story. These must be done before story points can be voted by the whole team, something that's done in the second part of sprint planning.
Task break-down may be performed "off-line" between sprint planning I and sprint planning II.
Tasks should be more than a summary, but should not be a micro-management tool doing the developer's work. Nonetheless, expectations can be provided as detail. For example, if it's expected by the lead engineer that to accomplish a specific programming task, he'd like to see a formal pattern used by policy, for example, the Factory Pattern for producing the dog polishers for various-size dogs, then this choice might be stated. The more recent or junior the developer, the more detail to provide. The more detail provided, the faster the task will be accomplished and the better the "natural" design documentation consultable afterward.
Once there's a pile of stories to choose from, the whole team reassembles to perform the more important part of sprint planning. During this phase, the team
Step 1 is when Scrum poker is played, if the team wants. What is the value of the poker cards? It is two-fold. First, it reminds the team to use the Fibonacci-like numbers as a standard in attributing story points. Second, it encourages them not to agree brainlessly on a value.
If things are working as they should, a consensus should be reached, but higher and lower suggestions should be reasoned. The benefit is that if a team member says 8 when others are saying 5, he gives his rationale. Maybe the rest of the team have over-looked something that will substantially bulk the effort before voting again. Maybe the story is easier than assumed. This should come out at this point.
When should Scrum poker not be used?
If the team is larger and some members tend not to grok the technical breadth of the stories, then Scrum poker quickly becomes a waste of time and lacks interest for many team members. Newer developer will be at a disadvantage in assessing complexity, but if many team members struggle similarly, though experienced, then the exercise is frustrating and disintegrates into a game of picking card values carefully to match the points attributed by those who obviously do know.
The larger the team, the harder it is to assess and execute stories making velocity a weaker and weaker indicator of team ability.
Step 2 is to list the resources the team has. If the team has dwindled in size, it likely won't produce at recorded velocity. If the sprint falls across a holiday- or vacation season, not as much work can be done as when the full team with the full number of working hours at its disposal can be dedicated. A simple ratio can be used:
Normal team size x full hours = Disposable hours Average velocity x
Where x is the substitute velocity to respect when attempting to peg the new sprint's expectations in terms of story points.
Step 3 should usually tend to push stories back onto the backlog that the team can't finish. This is a good thing for two reasons. First, it tends to keep some stories in full, ready state there so that, second, über-groomed and ready stories can be pulled from the backlog during the sprint when the team out-performs itself.
Last, the sprint is declared to have begun. This requires the cooperation of the team who, as pigs with skin in the game, declare their support for the sprint as defined. In some Scrum cultures, this is a fist of fingers, a 1-5 expression of confidence that the sprint is doable.