Ready, Set, Go!

Ready, Set, Go!

At the beginning of most races the starter will say something like, “ready, set, go.” At the team-level the concept of ready to develop acts as a filter to determine whether a user story is ready to be passed to the team and taken into a sprint. Ready to develop is often considered as a bookend to the definition of done. As a comparison, the definition of done is applicable both at the team level and at scale when multiple teams are pursuing a common goal. In practice, ready does not scale as easily as done. Ready often requires two sets of unique criteria for scaled Agile projects, Ready to Develop and Ready to Go.

The most common set of ready criteria is encapsulated in Ready to Develop.  Ready to Develop is used at a team level.  A simple set of five criteria are :

  1. The story is well-formed.
  2. The story fulfills the criteria encompassed by INVEST.
  3. A story must have acceptance criteria.
  4. Each story should have any external subject matter experts (not on the team) identified with contact details.
  5. There are no external dependencies that will prevent the story from being completed.

These five criteria are a great filter for a team to use to determine if the user story they are considering for a sprint can be worked on immediately, or if more grooming is needed. Teams will gravitate toward work they can address now rather than work that is ill-defined. The same predilection is true when viewing work being considered by a team of teams (an Agile Release Train in SAFe is an example of a team of teams). However, a team of teams needs a higher-level set of criteria to define whether they are ready to begin work. The Ready to Go criteria I most use includes:

  1. The teams have synchronized their development cadences. Synchronizing team cadences and agreeing on a team of team cadence is a powerful tool to ensure communication and integration.
  2. A sufficient groomed backlog exists. Identify and prepare enough work  (see the team-level criteria) to begin and sustain the teams that are in place, but no more. The backlog does not need to be complete (or completely groomed) before work begins.
  3. Enough of the architecture and standards have been defined. The SAFe addresses this issue by developing an architectural runway for the developers. Just enough design and architecture is developed ahead of the development teams to provide the guidance they need just before they need it.
  4. Knowable constraints have been identified. Constraints typically include attributes such as due dates (for example legal mandates can lead to hard due dates that even Agile teams need to accommodate), fixed budget, available capabilities and perhaps physical or technical constraints.  Everyone on ALL teams must be aware of the constraints they will have to perform within.
  5. The required infrastructure has been implemented. Infrastructure is the basic structures, tools and services need to deliver value. If you are delivering software, your infrastructure needs could be as simple as a place to sit and consistent access to electric power or as complex as servers, routers, networks, and development tools.
  6. Teams and roles have been established (and if needed filled). Make sure you have organized and staffed the teams that will be involved in the effort (assuming that you not using standing teams), and identified and trained any ancillary roles (e.g. build master or DevOps team). Organizing and staffing teams on the fly is an accident waiting to happen.

Implementing the concept of Ready to Go for starting scaled Agile project, release or program increment (SAFe construct) has a different goal and therefore different criteria than Ready to Develop. When the starter calls out ready, mentally run through the criteria for whether you are Ready to Go in order to begin work at scale.  Once you clear that hurdle you can apply the second set of unique criteria that is Ready to Develop.  Using both you will be more apt to sprint from the starting line when it is time to GO.