It’s interesting to observe that a lot of Scrum teams put a heavy focus on what the definition of done should be. A lot of time is spent meticulously ensuring that their customer has thoroughly defined through acceptance criteria what will signify a completed user story.
One element that often gets far less attention than the definition of done, if at all, is the definition of ready. Arguably it carries more importance than defining done because after all, if we don’t know when we should start then we have no chance of knowing when we are finished.
Agreeing as a team what the necessary requirements are before you can comfortably commit to writing your first lines of code is critically important before every project starts. It can be easy, however, to get so caught up on defining what ready means that you start to lose value in what you’re producing. Or worse still, wait and wait for that “perfect moment” to start that you deliver no value at all.
Andy Hiles visualises this perfectly with his graph:
It reminded me that more often than not, you need to get to a place where you’re comfortable with the unknowns that are ahead rather than try to understand everything before you deem something ready to work on. If your knowledge is too low however, then it’s going to cost a lot for the team to discover the details as they go. Similarly, if you spend too long mitigating the unknowns before you begin, you’ll bleed cost in other ways.
The sweet spot is somewhere in the middle. Know enough to be confident in what you’re about to embark on, but keep some of the decision making for when it needs to be made. Finding a comfortable level of unknowns (and a required base of known knowns) can push creativity and importantly ensure that you’re not waiting too long or wasting valuable time before you start sprinting. A team sat doing nothing is of course delivering no value at all, but comes at a cost all the same.
As a team, it’s important that you find a level of unknowns that you’re all comfortable with – but it is important you find that level and consider any risks that might be associated. For example, if your ideal definition of ready is that a technical specification document is present, but instead you have are solid user stories and technical people who you can ask questions of, ask yourselves if you can deliver value with what you have.
The chances are that you can. The chances are also that if you don’t accept a reasonable level of unknowns, you’ll lose a tremendous amount of potential value along the way.