Not to make sweeping generalizations, but a lot of people involved in software development and technology are on the cutting-edge. This means we like to be first, always learning, and get excited about what we’re working on. These tendencies naturally created the frenetic software development era of the 80’s, 90’s, and early 2000’s – all-night coding sessions, weekends spent at the office writing and fixing code, and the ultimate rush of the product release.

Thankfully, agile software development has largely erased these frenetic days and months of development, testing, fixing, release, and patching. However, as software developers, testers, designers, and product owners, we still have that desire for excitement and satisfaction. The question then is how to achieve and maintain these rewards with the steady and flexible approaches of agile software development.

It all comes down to being ready. For many teams, the aspect of ready is overlooked or not even acknowledged. All agile software development teams are familiar with the meaning behind done and know how critical this label is to the success path. The same value must be applied to being ready.

Done vs. Ready

It’s not uncommon for agile software development teams to be confused over the differences between done and ready or to simply ignore the importance of these two success variables.

The Agile Alliance defines done as: The team agrees on, and displays prominently somewhere in the team room, a list of criteria which must be met before a product increment “often a user story” is considered “done”. Failure to meet these criteria at the end of the sprint normally implies that the work should not be counted towards that sprint’s velocity.

In other words, the team agrees on the measurable factors that must be met to guarantee the story work is completed. By applying the status of done to a story, the team is stating that this piece of work has been properly coded, thoroughly tested, bugs are fixed, and it’s ready to be integrated into the product or feature. Of course, each team must create its own unique definition of done, the key being that the application of the done label is not rushed or pushed on work that is in fact not done.

The Agile Alliance defines ready as: By analogy with the “Definition of Done”, the team makes explicit and visible criteria (generally based on the INVEST matrix) that a user story must meet prior to being accepted into the upcoming iteration.

Meaning that in order for a story to move from the product backlog to the iteration, it must meet a set of defined criteria. The purpose of this so-called staging process is to ensure that stories are clearly defined and understood before the team begins the development, quality assurance, and design processes.

By using the INVEST matrix as a reference in defining the definition of ready, the team knows that they are keeping the best interest of the team, the organization, the client, and the overall goals of the project in focus. In brief, the INVEST matrix ensures that each story is:

• Independent (of all others)
• Negotiable (not a specific contract for features)
• Valuable (or vertical)
• Estimable (to a good approximation)
• Small (so as to fit within an iteration)
• Testable (in principle, even if there isn’t a test for it yet)

With these measurable and largely quantifiable variables, teams are able to use basic definitions and criteria to keep the processes of agile software development working for them. Work isn’t started without understanding its value and resource demands and this same work is only considered completed when it meets clear standards outline by the team. This is all done in the effort to maintain and ensure a flexible, manageable, and goal-oriented software development environment.

Ready – A Caveat

Surprises, missteps, blockers, delays, cost overrun, and excessive resource demands are all mitigated with the correct application of readiness. Missing this crucial variable and leaping straight into an iteration can result in the team working on a jumble of incomplete stories that result in the very chaos and communication break-downs agile methodologies are designed to prevent.

But, wait there’s more – we don’t want teams to get so caught up in defining the readiness of a story that story development is stalled. An underlying fear or concern can fester amongst the product owner, Scrum Master, and PMO that inadvertently stalls the progress of the teams. The fear of defining a story as ready before it is really ready – is a real thing.

As with all aspects of agile software development and management, teams and their leaders must remember not to get caught-up in the definitions of key agile processes. Cutting corners is of course not recommended, but neither is a slow-down in progress for fear of not applying the INVEST matrix or other definition of ready fully.

Take a close look at how you’re applying the definition of ready, the success rate of your stories when they do make it into the iteration, and where you can make improvements. Is your team underperforming because there aren’t enough stories in the iteration? Are the stories too small to actually be effective and resulting in integration issues? Have you simply become too granular in defining user stories – stalling them in the backlog and slowing the rate of progress? Remember, the cornerstone of agile software development is in being flexible – don’t forget to apply this to your definitions and application of ready.

Why Being Ready Matters

Keeping Ready In-Check

• Why teams can’t get so caught up in the definition of ready