Digital Community of SaaS Product Makers


Back to basics: User Stories and how to groom them

All these years being into Agile I have worked with many Products and have come across various ways of working and detailing features.

Many tools coming in market which allows you to write user stories and they follow some framework to do so but what actually should be the way of writing user stories?

The agile recommendation is to break down a set of user stories into smaller ones, containable into a single sprint duration, or ideally, a user story shouldn’t last more than a week.

One thing to keep in mind is that some of the agile “best practices” are to avoid having child stories, it is not a good recommendation to have user story in nested hierarchy, as that is also hard to model with stickies on a whiteboard.

There are some tools providing support for nested hierarchy of user stories, but you should avoid it. Keep the stories as a flat list, all at the same level.

What user story is really for?

User Story is only meant to describe a feature, but not describe how to implement it, meaning leaving out the technical aspect, it should describe the behavior or flow from user’s perspective.

How to run grooming session for the user stories?

It’s always good to groom user stories with the team before having Sprint planning meeting!

  1. You can invite people from technical team, not all members need to be there, but some senior members, architect or someone with good knowledge about the user story in question should be invited, then there should be people from business, sales or stakeholders, the internal customer they people who requested those user stories.
  2. It is important to run the meeting as timeBox for 1 hours, more then that its waste of time, you can have biweekly shorter meeting, its not a good idea to spend 3 hours for grooming session, as its not very productive.
  3. Go through the user stories in detail, try to finalize the open questions, perfect your mockups and describe and verify your user flow.
  4. Take meeting notes and write clear action points like what to be updated by who, etc
About author

Enthusiastic and versatile young Business Professional with Strong Engineering Background with 9 years of diverse experience in multiple domains like Table Games, Fin-tech, Payments, Social Networking, and Automotive. Through this very exciting journey on products of various domains, I have donned multiple hats ranging across Product Management, Customer Relations, Business, Tech, Quality Testing, UAT, client handling and surveys that take the business to another level.

Leave a Reply

Your email address will not be published. Required fields are marked *