Sprint Planning with: just in time decisions and negotiation

Some time ago I wrote about the Sprint Planning. I said that it’s the last line of defence of your Sprint. Why did I name it the "last line of defence”? Just because it is the last chance to get things out of the way which are not ready for development or blocked. What if the last line is under attack and there are some requirements you are not sure about to discard or give it a try. That’s the time when negotiation comes into play. You sit together think, talk, and test your ideas to tackle it down. Sometimes you get it and sometimes you won't. If you are still unhappy with the results of your discussion, you need to decide how to proceed...

Negotiation and just in time decisions

One thing to negotiate in a Sprint Planning is scope. Another matter is what function really means and how much function is required to solve the problem.

And sometimes there are even a few more decisions to make and unfortunately we are only at the start und need to decide a little bit later, when we can inspect what we built. I’ve got good experience with this kind of scenario:

You’ve got some kind of requirement and it is not obvious how to solve the problem because there are a few (1-5) tiny decisions which seem equal and cannot be solved by discussion. Cannot be solved by discussion means to me that even if we talk about it we circle around or thoughts or people get distracted during the discussion. At this point we give it a try and set expectations about how the decision should be made later on. In other words we postpone decisions, we decide them just in time.

Maturity and decisions

Sometimes there is the question if only real mature teams are able to do this. I would say rather no or yes. I’ve seen both mature and immature teams succeed and fail. To me it is worth to give it a try und to start with limiting the number of decisions to make and to scale how big this decisions are. Even more important to me is to talk about this decisions, to value them and make it a part of our process or to talk about it what went wrong and what to try differently.


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.