No Bride, Just The Groom

Or. . . Do We Really Need A Grooming Session?

The teams that I work with generally look at grooming as a session in which we

take the handful of stories that our product owners or Business BAs have added to our “to be groomed” etherpad, and put sizing on them. Deviating outside of that feels like an exception.  Like any decent ScrumMaster, my job is to guide the team towards accepting that grooming sessions can (and should be allowed to be) so much more.  Every team in every company gets in a “rut” of comfort.  It’s no one’s fault that it happens.  It’s human nature to seek out the familiar.  If a ScrumMaster pushes “change” too much, the team gets uneasy.  Back off too much, and it’s rut time.  So here is a list of 6 (maybe 7) activities, any one or combination of should be allowed in the agenda of your grooming sessions.  By no means am I saying to attempt all of these in a single session.  That would rarely be practical.  My recommendation is to focus on attempting the 2 or three that are the most immediately necessary

1. Cleaning up the way a story has been written: It is not a personal attack on you if you have written a story that the team thinks needs to be re-written or changed for clarification.  Stories can be flawed and need to be tightened up.  The quality of the story being used for guidance during the sprint is the responsibility of the whole team.  i.e., if while grooming a story, the “who” needs to be clarified, or the “why” is unclear, then it is the team’s job to talk through it to bring the story into alignment with what the original intent was, and what the acceptance criteria for the finished product will be.  It’s supposed to be a conversation. 
2. Splitting a story into smaller pieces or even determining that it is an epic: It is not a sign of anyone NOT doing their job if, while discussing a
   

   story, the team decides that it is more like an epic and needs to be broken into smaller pieces, or that it needs to be broken out into an additional story.  BAs and Product owners should strive to keep that to a minimum, but it is actually a healthy sign when it happens–it means the team is no paying attention to delivering the smallest reasonable piece, and at the same time, it means the Product owner pr BAs have a bigger picture in mind for what needs to be built.

3. Tweaking priority and mid-range planning:  I look at the Product owners or Business BAs as the mayors of backlog town–they govern it, they have the authority over it, but they also have things that they do not have control over being done in their town.  Development teams may write technical debt stories that they want to have considered.  During grooming, the development team may want to have one or more of those technical debt stories considered for grooming or for prioritization.  In any case, the backlog will contain a whole variety of stories, and over time, we’ll need to take a look at a logical sequence to release those items.  Some may be dependent on others while others may make more sense to be bundled together to reduce the amount of churn the customer might experience. Periodic reviewing of the overall backlog allows the team to plan out work around release schedules and perform mid-range planning.  That is another article unto itself; indeed, Mike Cohn has written an excellent book on the subject.:  Agile Estimating and Planning.
4. Estimating backlog Items:  This is one of the two things that most teams associate with grooming.  Every team I have ever worked with can wander into the “Let’s build it now” trap.  That is, they begin to debate how they will do the actual work under the guise of determining how many points worth of work the story represents.  It’s human nature to want to talk through how to build something–planning is what Engineers do.  But over-planning is how you kill momentum.  All ScrumMasters (and every member of the team) has the responsibility to politely stop the discussion and ask–“Will the things we are debating here  impact the size of the story by any real
   

   Don’t let them trick you!

   magnitude?”  Another way to keep from going down the rabbit hole is to engage Triage/rapid-fire sizing.  I.e t-shirt sizing (S, M, L, XL) followed by estimating.  The breakout looks like this S= 1,2, or 3.  M= 5 or 8, L=13 or 20, XL= everything bigger.  For example, after sorting out the acceptance criteria, the team looks at a story and gives it a t-shirt size of medium.  The debate then switches to whether it is a high medium or a low medium.  The team says it seems like a low medium; BAM! it’s a 5.  Try this exercise once–really rapid-fire.  Hide those estimates and then do a more traditional sizing.  You will likely be surprised how accurate the much faster version is.

5. Adding acceptance Criteria:  This is the second of the two things teams usually associate with grooming.  As in estimating, while adding acceptance criteria, the conversation can very easily lead in to the “Let’s build it now” trap, and, likewise, very similar self-governance applies here.  It’s everyone’s responsibility to ask: “Will the things we are debating here clarify what acceptance of this story looks like ?”  Adding acceptance criteria should be the point where the team really gets down into the requirements they need to know to build the story.  Capturing the acceptance criteria puts the “frame” around the work, solidifies the effort for QA, and often forces the team to re-visit the story’s verbiage.  THAT’s where serious stumbling can occur.  (See item 1 above).  Everyone on the team–including whoever wrote the story–needs to be OK with re-structuring the story and its contents because (I’m about to shout something, it’s that important) DETERMINING WHAT WILL HELP OUR CUSTOMERS IS THE MOST IMPORTANT PART OF GROOMING.
6. Clean out the closet: Anyone on the team is allowed to write user
   

   stories.  Most of the time Product owners and BAs write user stories for features and changes, but Developers and testers should write technical debt stories whenever they see something that will need to be corrected (Writing technical stories  so that Product Owners can know the value deserves a post of its very own–and will likely get one).  Anyway, over time, there may be “old clothes” in the backlog–work that was once considered a priority item that just keeps getting shuffled away and is no longer important.  Like an old item in a closet that you can’t bear to throw out: “I LOVED those pants, but they’re just not back in fashion yet!”–some stories were beautiful when they were first created, but they may no longer be practical or even necessary.  It’s OK to take note of those old requests and either go back to the stakeholder to ask them if it is still important.  In many cases stakeholders are will discard them.  In others. they may need to understand why the story is obsolete.  That’s not a bad thing.  It’s why, in Agile,  we value feedback over getting it perfect the first time.  The changes that are important bubble to the top, and the work that was once important fades away.  It’s not a criticism of anyone that this happens.  It’s a by-product of technology and its tendency to rapid transformation. 

7. ish –Write user Stories:  I have heard that some teams take time to actually write stories during grooming, but I suspect that the stories aren’t being written from scratch.   I don’t coach my teams to show up at grooming with the expectation of writing stories out of thin air.  What many teams do, however, is re-write stories,  or write technical debt and/or release stories, or even create new stories after splitting up larger ones.  If any reader is on a team that is writing stories from scratch during grooming, I would love to hear how that evolved.  Maybe I’m missing something.

So, the next time you are headed to grooming and someone grouses–“We don’t have anything to groom.  Do we really need to have this meeting?”  Just remind them of all the options we have for grooming.  If you are a ScrumMaster, make it your priority to work with everyone on the team to figure out what agenda would benefit the team the most.