Over a million developers have joined DZone.

User Stories - How detailed it should be ?

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

Data Flowchart During the initial days of requirement gathering session, the product owners end up writing the epics. These epics needs to be broken further down into the user stories .   One common question repeatedly asked by the novice product owners is when is the right time to stop splitting the user stories ?   

If you Google around there are many articles written about this topic. 

Some of the options proposed by various authors include:

1.  Stop detailing when you feel the user story is big enough to be implemented in 3 – 4 days

2. Stop detailing when you feel the user story can be implemented in one iteration

3. Quite commonly referred acronym is the “INVEST” model.  More details about this model can be found here,   
I really like the INVEST model however,  if the Product Owners(PO) and developers are new to Agile, the above model will not help them much. I still feel that it looks pretty abstract to them.  

In one of the real world case studies, a group of “new to Agile”  product owners and developers  applying the INVEST model on user stories got into a debate for couple of days. They were not willing to budge with their own understanding of  “What testable” means, as each of them had their own explanation.  

So, just telling some one to follow the INVEST model may not be sufficient.

I have my own opinion about this,  while I am coaching the Agile teams, I recommend an iterative approach to detail out the user stories. Each time the user story is created, I ask the product owners to apply the INVEST principle to begin with and then share it with the development team to check their confidence level . If they are able to understand it easily and say that they can code this story, then probably it is the right size.   If not,  then the user stories needs to be split or detailed out further.  The developers take the important seat here. The developers need to review it because, they are the people on the ground implementing the same.

If the team is working in distributed model with POs  and developers distributed across the globe, then the POs could write the user story on Wiki or JIRA kind of tool . The developers on the other end can write their comments/questions as part of the feedback loop.

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Venkatesh Krishnamurthy, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}