Skip to main content

Top Tips For Breaking Down Epics/Features Into User Stories

Last post 04:19 pm July 16, 2020 by Ian Mitchell
3 replies
02:36 pm July 16, 2020

Hello! 

I have been a PO for one year and feel I have a grasp on my day-to-day duties. One thing I would like to get better at is laying more of a runway in the product backlog for the devs. In order to do so, I need to get stronger at breaking down Epics to Features to User Stories.

My question is what basic questions do you ask or basic steps do you take when breaking down Epics/Features/User Stories? 

It takes time to develop the intuition so maybe some basics to start. 

Cheers!

 


03:30 pm July 16, 2020

The first question I ask is how much of this Epic can be done in a single Sprint and still deliver an increment that can be reviewed by the stakeholder in order to gain further information?   That is your goal to breaking down stories, make them small enough to be completed in a single sprint and have something that the stakeholders can review to provide feedback.

It is not always easy to go straight the Sprint sized items so you may have to work down to that level.  For example, if the Epic involves a new UI that will allow users to view, enter, modify data that is stored in a database.  Break it down to each of those actions.  Then break each action further if possible. 

Having said all of that, it is not your job exclusively to do so.  This is something that the Development Team must participate in. They know better how to break down based on the technology so your best chance of breaking stories is to involve the Development Team, i.e. refinement.


04:09 pm July 16, 2020

Sticking with Daniel's example of the UI that allows a user to view, enter, and modify data that is being stored... from a PO perspective I may think about the incremental creation of this in terms of value to the customer / business when working with the Development Team.

For example, if the customer is currently submitting this information via paper form there may be value in working on the 'view' feature first to allow them to at least see what they have submitted. In addition, there may be a return on investment to the business in the form of decreased phone calls to inquire about the status of a particular item. 

Barring some technical constraints I may prioritize the view feature high because I could release it to our customer base while the team works to create the enter and modify pieces. 


04:19 pm July 16, 2020

what basic questions do you ask or basic steps do you take when breaking down Epics/Features/User Stories? 

Are the team satisfied with the acceptance criteria so far provided? Are they testable? When this matter is thought through properly additional detail will often emerge. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.