Step by Step handbook for Agile Development. Part 3, Pre-Grooming and Grooming.

Pre-grooming

Frequency:

• As many times as needed, iterative process
• Mandatory –  release leads, UI/UX, program and product owners (story writer)
• As needed- QA leads, Stream leads and developers as SMEs
• Optional –  head of development, head of product

Participants:

• Mandatory –  release leads, UI/UX, program and product owners (story writer)
• As needed- QA leads, Stream leads and developers as SMEs
• Optional –  head of development, head of product

Description

Pre-grooming is the process by which a story is evaluated for readiness to go into the backlog for grooming by the team.

The story is ready if it is well articulated, concise and contains all of the necessary information that a developer would need to point it and immediately start on the feature. If a story is not ready to be started it should not go into the grooming process or into the backlog.

On the other hand if the story will not be executed, or at least started, sometime in the next two to three sprints (depending on the sprint length) they should not go into the pre-grooming process at all.  The reason for this is that the story may still change.  Even though it may be considered complete if there is no desire to start development immediately it indicates that there are other higher priority stories that should be tackled first.

Attributes of a Good Story

• Each story should be independent from all other stories in the sprint.  In other words; a developer should be able to complete it and releases it as a single independent feature
• If there are related stories or stories that are dependent of each other they should be grouped under a common epic
• If the story is too big it needs to be split into multiple stories and grouped under a common epic
• If the story is too small it should be combined with other small stories if possible and logical
• The details of the story can and should be negotiated between the story writer and the team conducting the pre-grooming and grooming if it is needed
• Each story should be written so that the value to the customer is clear to all who read it
• Story should focus on the “What” not the “How” of how it will be executed
• Each feature articulated in the story should be testable and, if possible, the testing metrics articulated
• Details for the story should appear as attachments and annotations, not as part of the main story.  Not all of this will come from the story writer, but the story writer, program manager and development lead should all work together to gather this information during the pre-grooming process.  Some examples of this are:
  • Annotated wireframes, mock ups or creative.  Only what is changing or relevant to this one story should be included
  • Error  messaging and page text
  • SEO information
  • Sample XML or any other data that a developer will have to code against for this story
  • Relevant schemas
  • Etc.

Goal

Through this process the participants attempt to anticipate developer and QA questions prior to grooming and provide all of the necessary collateral for development and test writing to begin.

Questions to be asked and Gates to be opened

• Can  a unit test be created (y/n)
• Can automated QA be created (y/n)
• Does it require full regression (y/n)
• What components can be made part of the common code repository?
• Does it adhere to the style guide or does the stile guide need to be updated?

Output

• Finished stories ready for grooming and in the backlog
• All of the necessary supporting information, data and creative required to start the development and testing process

Approvals required to move to the next step

• Head of development team or designated second(s)
• Head of product team or designated second(s)

Grooming

Frequency

Ideally once per sprint, per agile team, but no more than twice. If a story is deemed to not have enough information to point by the development team at the time of grooming, and the requested information or answers cannot be provided in time for the second scheduled grooming meeting, then the story will be sent back to pre-grooming for one more pass.

Participants

• Mandatory –  Team (stream) leads, developers and QA analysts in the agile team that will be developing this story,  product owners (story writer) and program manager/SCRUM Master
• Optional –  dev head, product head, release leads, QA leads

Description

The grooming is intended to allow the actual developers and QA analysts who will be responsible for delivering the feature(s) being groomed to get answers to any remaining questions and for them to point the story(s).  This is not intended as a group exercise and should not be attended by anyone who is not working on the stories being discussed.  The only exception is if there is a team working on stories that are dependent on the stories being groomed, or if the stories being groomed are dependent on the stories being worked on by the other team in question.

Steps in a Good Grooming

• Ensure everyone attending has read the stories being presented before the meeting.  If not scrap the meeting
• Determine if all of the QA and development resources that will be working on the story fully understand the requirements.
• Stream lead and program management must ensure that the team asks questions and is comfortable with their understanding of the requirements before the team points the feature
• Negotiate the details of the story between the story writer and the development team as needed
• Provide point estimation of the effort to bring the story to fruition.  Ideally this should be done through the use of Pointing Poker.  This estimation of effort needs to take into account the following efforts:
  • Dev/QA prep
  • Unit test development from the developers
  • QA test automation from the QA team
  • The writing of the test cases
  • The effort to code the feature and enough time to account for the time that will be needed during bug remediation
  • The effort to QA the feature and re-QA the feature after bug fix
  • The effort required to create or gather data needed during the QA process

Goal:

To provide estimation of effort and to determine how many stories should go into a sprint.  Prioritize the order of those stories and decide which stories should go into the backlog.   To negotiate on the details of each story to make sure it is achievable in the most efficient manner possible.

Output:

• Assignment of story to correct agile team
• Point estimation of each story
• List of stories in sprint
• Priority order of stories in sprint
• List of stories in backlog

Approvals required to move to the next step

• Release leads
• Stream leads
• Program

Next time we will go into Planing and Good Backlog Management.  Drop me a line if you have any questions and thanks for reading.