How to scale definition of done - When to do what?

A common question about definition of done is - "When should we do which activity?" A definition of done is usually about:

  • Done when the story is done
  • Done when the sprint is done
  • Done when the release is done

Usually you should strive to be done as soon as possible with the most activities, so do the most stuff at story level except there is a reason not do.  Here are several why you might scale your activity from story level to sprint or even release level.

Transaction costs, synergy or no demand

The result of adjusting focal distance while taking the picture. By  B166ER at the German language Wikipedia GFDL or CC-BY-SA-3.0, via Wikimedia Commons

Some activities should be done for all stories and it is cheaper to execute them together, usually activities for non functional requirements fit here. Take for example performance testing or testing with data from live systems. If you do it once a sprint it might be enough. Moreover, there are different opinions about how much e. g. security is required per story, this happens per stakeholder. Sometimes there might be no demand to do the activity per story.

Minimum viable product and experiment

Sometimes you want to experiment functionality. You develop it without making things nice and layout it the way it fits into the GUI design. This approach is fairly okay, because you want feedback, you wanted to test your idea. This is often when you go for a minimum valuable product. You might run a few sprints with making it run and before the release, after you said - "this is it" - you make it nice and fast. 

Low performance, too many restrictions or impatient stakeholders or customers

If you spent too much time with developing one story and you cannot get enough features done. Then you might suspend some activities for later. This is also recommendable if you've got impatient stakeholders or customers. Show that it works and then make it nice and fast.

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