Sprint Planning - The last line of defence

How to enter a development bastion?

Still teams get stucked because the requirements they work on are not ready for development, because questions have not been asked, key questions not been answered, stakeholders not involved and the most ugly part: decisions not been made. So a lot of teams have to start with rather poor sprint backlogs.

To be productive and have fun with your work, you want no distraction from you work. You usually don't like to be blocked because of poor decisions or no decisions at all. As a developer you are standing in the last line of defence, because if nobody decides, you will make the decisions. 

 

"In a fortification with bastions, the citadel is the strongest part of the system, sometimes well inside the outer walls and bastions, but often forming part of the outer wall for the sake of economy. It is positioned to be the last line of defence should the enemy breach the other components of the fortification system." (Wikipedia)

In the shield wall

Ivar’s shield wall had held, but I could well imagine the ferocity of that battle.
— The Burning Land, Bernhard Cornwell

Standing there in the last line of defence you as a developer take it as a bastion to defend your sprint from distraction and blockades. Ask questions, demand decisions, make decisions, share your insights and if planned work is poor, then reject unclear requirements or stories. 

Sprint planning is a tool to be used. On the one hand it is about telling stories to get a common picture or to plan your collaboration, on the other hand you might use it as a shield to protect your performance. If you use sprint planning als shield and sword, then you show that there is a responsibility about making work ready. Remember you are involved in making work ready and you have to play your part.

You might try to add some components right in front your last line of defence:

  • Try to get stories small, because small stories are easier to understand.
  • Get stories ready for development for about 1 or 3 weeks before a sprint.
  • Use estimation or grooming sessions to ask key questions. Remind people about your questions constantly (as a scrum master, be a mosquito).
  • Make teams cross-functional or involve the people who can provide information. 
  • Write down the essential parts of your stories which need to be solved before (make it explicit and visible). This might result in a definition of ready.
  • Reject stories in the sprint planning, to show that essential parts of your stories are missing (do that in a responsible manner). 
  • Visualize at a wall which stories are ready for development. A product owner might suggest, but the team decides. 

SVNWNK