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

  

Definition of ready - Your sword in the shield wall

The definition

A definition of ready is used to produce story readiness. A story which is ready for development needs to meet criteria. Thus criteria defined is required to accomplish a story. The definition of ready is an activity of the development team to state everything what's required before development begins. It is also a contract between development team, product owner and stakeholders. A development team has to contribute that the criteria is meet as far as possible. If criteria is missing from stakeholders or product owner the team should deny to start the work or close the gaps with own decisions and suggestions. The definition of ready is a tool to make explicit and transparent what is needed to start a story and can be used for developers as last line of defence.

The sprint

The goal of a sprint is to deliver working software in the state of done. The delivery is called potential shippable product increment also known as usable software ready for installation.

The battleground

To deliver a full working software due to your definition of done there are preconditions to be met before you can start your work. E. g. you might need several documents in advance like text, math and formulas, design and so on. On the other hand you as a development team need to specify which criteria has to be met to validate that you build the right software.

The battle and the sword

A Seax photographed by Bullenwächter, GFDL or CC-BY-SA-3.0, via Wikimedia Commons

In order to complete a story within a sprint every part of the story must be delivered in time, otherwise the team might be wasting time with waiting during a sprint, will not deliver or will have to adjust the delivery later on. Furthermore, to avoid waste of specifying stories too early the timeframe of making work ready is set very close to development. To dissolve those contrary interests - that is the battle. Like in a shield wall you have to push forward and should not loose ground.

Cutting through dependencies in a tight schedule between preparing the work and implementing it is tough. On the one side you shield yourself against getting blocked and deny work which is not ready for action, on the other side you have to contribute to get the work ready and must be aware what is required to start. Both sides are the cutting edges of your sword. 

SVNWNK

 

Different projects in a sprint - Juggling with knives

There is often the question: Different projects in a sprint - does it work? The answer is either yes or no! 

Yes, it works

When you use sprints, you might use Scrum. Scrum is a framework. You take it and put the work in that frame a sprint is offering you. Once your work is in that frame, you can work on it, no matter if it you are delivering for one project or serveral. You might loose focus because the projects are tearing you apart, but as long as you are able to stabilise the priority of you work during your iteration there is chance to succeed. And you still got a ScrumMaster to support you.

No, it does not work

By David Shankbone (David Shankbone (own work)) CC-BY-2.5, via Wikimedia Commons

It will not work, if you do not put all of your work into that frame. Leaving work out of your sprint will lead to distraction and waste. Usually while there is work happening outside that is pulling your attention, this work is not weighted against the work in your sprint. There will be waste through discussions about priority and unfinished work to resume. On the other hand when there is to much ad-hoc work you will run into trouble too. Ad-hoc work is similar to work which is not framed - and yet a little bit different. A sprint is also under policy: do not disturb the people working. If your workplace produces too much ad-hoc work the process you've selected will be under constant need of maintainance, so the system will need other desire paths than your process might provide, unable to heal itself.

There is still hope

You can learn about your environment and work situation. Just make your work visible, put your work on a taskboard and follow its flow from introduction to done. Visualize the problems and impediments you encounter and improve around all mistakes that happen. It might be a hard road and it is worth it. Usually this is true: "Only what is visible can be improved."

Different projects in a sprint - it's like juggling with knives, it might work or it might hurt... 

 SVNWNK