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.

SVNWNK

Ready ready* for the hammer

Some time ago I've read lamentations about story readiness and why is it bad because of it is destroying the intent of user stories. First I was amused, later on I was afraid that people will take this for sure. I do recognize that there is truth in this post, so far that people still miss using conversation - direct face to face conversation - and sometimes the concept of story readyness is taken for specifying user stories too far in advance and detail. Let me revisit this statement later on.

What is story readiness?

Story readiness is an artefact of the team. It is a contract and a visualisation about the what the team needs before starting in order to deliver working software within a sprint. First of all it is an activity: The team decides what parts are essential to work before starting it: "what should we collect to work on stories in a flow state, okay let's write it down." Now the teams knows the important parts to collect within their environment and this is the most important part of it - knowledge and visualisation as baseline for improvement. Using this artefact and sharing it with the other stakeholders is an act of fairness: We show you what we need to start (sure not everybody is interested in, but this is not the point). 

Now we've made the rules and circumstances explicit, we know as a team what to ask, what is important to us, what are the cornerstones we have to get clear. The performance of any team is in exponentially proportional dependency to the state of the work you start and you should start the ready work. Using story readiness as a contract between product owner and team means you declare a last line of defence to deny work wich is not ready for development.

Revisiting it

The intent of a user story is face to face conversation about the why, the whereof the story. Story readiness deals with what should we talk about to get the story ready, what has to be in place, so that you can start. If you do not know what you need to talk about, the conversation might get cumbersome. As said an user story conversation is about the value the story should provide and a discussion about different ways of implementation the function part. Even if this happend perfectly, the team is all fine with the intention of the user story, defined functionality and everything they need to get the story done. What if the parts the team needs from outside of their circle won't be delivered in time? What if the last line of defence is breached, because the team took unready work into a sprint and is blocked - well you had a nice conversation, but still important stuff is missing and work won't get done.

A definition of ready is a tool to be used. For sure teams with a classic requirement engineering background tend to do much requirement engineering in advance than agile style, this might lead to waste, but not definitely. Sure a team might not feel responsible for making the work ready, then you might use the readiness to check what the team thinks it can contribute and work on the items which they do not consider under their influence. As a scrum master you got a nice tool to show your team and management where improvements can happen.

Still you as a team are responsible to get the work ready, you might use the story readiness as a contribution to your last line of defence, to deny work which is not ready for implementation and tends to block your delivery within your sprint.

Limerik

 

By Photographer''' Isabelle Grosjean ZACC-BY-2.5, via Wikimedia Commons

"If I had a hammer and hit me on the hand - would I say damn this shit should be banned?

If I had a hammer and something hit my hand - would I say damn shit the hammer should be banned?

If I had no hammer and something hit my hand - would I say damn I need a hammer to be banned?

If I had no hammer and nothing hit my hand - would I say damn shit nothing can be banned?" 

 

SVNWNK

PS: *Ready ready is a term borrowed from Jakobsen and Sutherland, "Scrum and CMMI - Going from Good to Great: Are you Ready-Ready to be Done-Done," 2009