Ready to develop insures that the team is ready to work as soon as they sit down.

Ready to develop ensures that the team is ready to work as soon as they sit down.

The definition of done is an important tool to help guide programs and teams. It is the requirements that the software must meet to be considered complete. For example, a simple of the definition of done is:

  • All stories must be unit tested,
  • a code review performed,
  • the code is integrated into the main build,
  • functionality has been integration tested, and
  • the release documentation completed.

The definition of done is generally agreed upon by the entire core team at the beginning of a project or program and stays roughly the same over the life of the project. It provides all team members with an outline of the macro requirements that all stories must meet. Therefore the definition helps in estimating by suggesting many of the tasks that will be required. Another perspective on the definition of done is that it represents the requirements generated by an organization’s policies, processes, and methods. For example, the organization may have a policy that requires the code to be scanned for security holes. Bookending the concept of done is the concept of ready to develop (or just ready). Ready to develop is just as powerful a tool as the definition done. Ready acts as a filter to determine whether a user story is ready to be passed to the team and taken into a sprint. Ready keeps teams from spinning their wheels working on stories that are unknown, malformed or are not understood. The basic definition of ready I typically use is:

  1. The story is well-formed. The story follows the format of persona, goal, value/benefit. The classic user story format ensures the team knows who the story is being done to support, the functionality the story is planned to deliver AND the business value the story is expected to deliver.
  2. The story fulfills the criteria encompassed by acronym INVEST.
    1. Independent – Development of the story is not dependent on other incomplete or undeveloped stories. This does not mean that any individual story does not build on a previous story.
    2. Negotiable – The story generates conversation and collaboration with the product owner and subject matter experts. Stories are not a contract rather they are a tool to ensure that business ideas are explored as the stories evolve from an idea into code. Stories are never a specific contract.
    3. Valuable – The story will deliver a demonstrable benefit when it is complete.
    4. Estimable – The team can accurately (enough) estimate the size of the story. The ability to estimate requires that the team has a decent understanding of what the story will require.
    5. Small – The story can be completed in a single sprint.
    6. Testable – The story can be easily unit and acceptance tested.
  3. A story must have acceptance criteria. Acceptance criteria are critical components in the definition of the story’s requirements. All acceptance criteria must be satisfied for the story will be complete (not necessarily done).
  4. Each story should have any external (not on the team) subject matter experts (SMEs) identified with contact details. External SMEs generally participate in the conversation and collaboration needed to deliver a story (N in INVEST).
  5. There are no external dependencies that will prevent the story from being completed. In projects in which the work is completed by a single team, these criteria is generally subsumed by the independent criteria in INVEST. However, in larger projects interactions with other teams, applications or factors can generate dependencies. Those dependencies need to be identified and cleared before a story enters the development process.

The definition of ready is a hurdle in much the same manner as the definition of done. The definition of done ensures that a team delivers functionality that meets not only the requirements of the product owner and business but also the requirements of the organization. The definition of ready makes sure that the stories that a team is asked to plan and develop are ready so they don’t waste their time and can deliver the maximum amount of value possible. Getting stories ready for development does not happen by magic rather the process to prepare stories is typically part of planning and grooming . . . but that’s up next.