Around the Definition of Ready

Some days ago we had the ret­ro­spec­tive meet­ing and as a kick off for the dis­cus­sion we want­ed to describe the sprint by using one word. Most of my col­leagues described their cur­rent sprint with “Suc­cess­ful” so we agreed to dig deep­er in the top­ic and under­stand what hap­pened, what were the fac­tors that con­tributed to this suc­cess, what activ­i­ties should we as a team con­tin­ue doing in the future.

To cut it short: team appre­ci­at­ed the flow of user sto­ry readi­ness result­ed from the fre­quent back­log refine­ment ses­sions we had pri­or the sprint start. This allowed us to bring to Done all the fore­cast sto­ries and have a good feel­ing also for the upcom­ing sprints.

We’ve con­tin­ued after­wards the dis­cus­sion about the char­ac­ter­is­tics of a good User Sto­ry, reviewed the INVEST check­list and brain­stormed about the cri­te­ria used when assess­ing a user sto­ry to be “ready” for development.

Some­one from the team exclaimed: “This could be our def­i­n­i­tion of ready! We can ask our Prod­uct Own­er to con­sid­er this cri­te­ria when writ­ing the user sto­ries! This will make our life so much easier!!”

After a cou­ple of sec­onds of silence, anoth­er voice could be heard: “But wait, we are writ­ing the User Sto­ries togeth­er with our PO. This prac­tice should be con­tin­ued also in the future!” 

What is the Definition of Ready?

The def­i­n­i­tion of ready is a work­ing agree­ment for the team that states what a user sto­ry must have in order to be planned in the next sprints. This tool can be very help­ful espe­cial­ly for teams that find them­selves at the begin­ning of their agile jour­ney, for exam­ple to strike the bal­ance between too much and too lit­tle detail when writ­ing user stories.

I’ve seen a lot of teams sprint­ing with­out hav­ing in advance the prop­er dia­logue between what is pos­si­ble and what is desir­able. Hence the typ­i­cal ten­sion between what is desir­able for the cus­tomers, what is viable for the busi­ness and what is fea­si­ble with the cur­rent tech­nol­o­gy with­in the tar­get time­frame is far to be resolved. One con­se­quence of this prac­tice is for Scrum teams to start their sprint with user sto­ries that con­tain too lit­tle detail, which makes them impos­si­ble to plan prop­er­ly. And this can be very frus­trat­ing as nobody wants to start work­ing on User Sto­ries that are too fuzzy to be suc­cess­ful­ly fin­ished inside the sprint. This is one of the sit­u­a­tions where estab­lish­ing a Def­i­n­i­tion of Ready can be extreme­ly helpful.

A double-edged sword

Some­times though, with the aim to build on top of the estab­lished Def­i­n­i­tion of Ready, teams start to become very strict about what “ready for devel­op­ment” means. Dur­ing their ret­ro­spec­tive meet­ings, they will try to con­tin­u­ous­ly improve their process and when­ev­er com­mu­ni­ca­tion prob­lems between Prod­uct Own­er and devel­op­ment team arise for exam­ple, the nat­ur­al ten­den­cy is to extend the Def­i­n­i­tion of Ready with a new pol­i­cy. After sev­er­al “improve­ment” ses­sions, some­one will real­ize that instead of the sil­ver bul­let that solved sev­er­al trou­ble­some sprints, they may have imple­ment­ed a wall, an over-reg­u­lat­ed process, that impedes col­lab­o­ra­tion between Prod­uct Own­er and Devel­op­ment team

And most of us have wit­nessed the nev­er end­ing dis­cus­sions on how the Prod­uct Own­er should spec­i­fy their require­ments cor­rect, com­plete and con­sis­tent, pre-approved if pos­si­ble by anoth­er Prod­uct Own­er (high­er on a hier­ar­chi­cal­ly scale) and also soft­ware archi­tect — “just” to make sure that the miss­ing details are cov­ered. And the sto­ry con­tin­ues with the devel­op­ment of tem­plates, process­es, approval meet­ings and so on…

Course correction

• What if the Scrum team uses the DoR dur­ing the back­log refine­ment ses­sion to assess the readi­ness of the back­log items and not as a sequen­tial, phase-gate checklist?
• What if we change the word­ing by gen­er­al­iz­ing and cre­at­ing guide­lines instead of mak­ing strict, spe­cif­ic con­tracts (between devel­op­ment team and PO)?

In case we real­ly need a Def­i­n­i­tion of Ready, we have to remem­ber to not for­get about the agile prin­ci­ples. As oppo­site to the Def­i­n­i­tion of Done which should grow along with the capa­bil­i­ties of the devel­op­ment team, the Def­i­n­i­tion of Ready should shrink, as the team will become more and more capa­ble to han­dle incom­plete information.

Teams must become more com­fort­able with uncer­tain­ty. When one thing can­not start until anoth­er thing is done, the team is no longer over­lap­ping their work. An agile team should always be doing a lit­tle analy­sis, a lit­tle design, a lit­tle cod­ing, and a lit­tle test­ing. Putting gates in the devel­op­ment process pre­vents that from hap­pen­ing and the estab­lish­ment of a def­i­n­i­tion of ready can lead direct­ly to such an approach.

What are your expe­ri­ences with defin­ing what ready for devel­op­ment means?