1

We are starting an Agile project, and the product owner has made a start adding user stories to the product backlog (mostly epics at this stage).

Who would be responsible for breaking down epics into smaller user stories - is it left to the product owner, or would you expect the rest of the team to be involved (bearing in mind they won't have any knowledge of the requirements or problem domain)?

Improve this question
5
  • 4
    Why doesn't the team (I'm assuming you mean the development staff, since the product owner is part of the team) have any knowledge of the requirements or the problem domain? If they don't, how are they going to be responsible for estimating the stories and deciding how much to bring into each iteration? Commented Nov 16, 2012 at 14:42
  • @ThomasOwens Because most organizations look at Agile as an excuse for product owners to desire software at a high level without having to actually define the details of what they want. Requirements can then become somebody elses problem, which is almost always the interpretation of the lead developer. I am in the same boat right now. Commented Nov 16, 2012 at 14:54
  • @ThomasOwens My only experience of Agile was working on a back-end web service that integrated into a legacy app. Most user stories were variations of CRUD operations, probably written up by the lead dev (as the product owner wasn't IT literate - he could only tell us what information a customer might want from the legacy db). USs were prioritised but not estimated. When it came to creating and estimating tasks during iteration planning, it was usually a no-brainer as most CRUD operations were much like any other and the problem domain was essentially just a large customer database... Commented Nov 16, 2012 at 15:19
  • ...I'm now working in the scientific industry and the new software project requires much knowledge of scientific instruments, maths, chemistry, etc. (a totally different ball-game to your usual "corporate" IT systems). The devs have little knowledge in this area, so I'm not sure what we could bring to the table to help break down the epics, as only the PO will know what functionality is required. I agree though that the devs should be involved, even if it's just to gain familiarity with the problem domain and requirements. Commented Nov 16, 2012 at 15:22
  • 2
    @AndrewStephens If the knowledge is highly specialized like this then not having an analyst on your team to help you with requirements and estimates would be madness. If that analyst happens to be the PO then he MUST step up to that role and should in no uncertain circumstances think that he can just give you epics and be done. This isn't even a matter of properly estimating anymore, it is a matter of even being able to implement the software. Commented Nov 16, 2012 at 15:34

3 Answers 3

Reset to default
7

As a general rule, the whole team is responsible for breaking down the epics prior to implementing them. It's fine to put the epic in the backlog and prioritize it, and then break it down just before the iteration in which it is planned for implementation. When breaking it down, the product owner (or other customer and user representatives) would help to identify the subprocesses of the epic so that it can be broken down into its constituent parts.

However, without an understanding of the problem domain or the requirements of the system, I'm not sure how the development team can have a conversation with the product owner, customers, and users about what they are delivering. Depending on the complexity of the problem domain, they might not have an in-depth understanding, but I would expect some kind of education about the customer's business and domain-specific terminology, the problems the system is trying to solve, and the general direction and high-level requirements of the system under development for everyone involved in the project.

Improve this answer
1
  • I'd like to add that the ongoing cycle of violence between the product owner and developers in terms of refining an epic is a part of the continuous feedback amongst all parties (not just customer to developers) as one of core points that Agile attempts to solve. Commented Nov 16, 2012 at 15:03
3

IMO, the team would be responsible for breaking down the epics into smaller user stories which while in the beginning will be a challenge is likely something that will improve over time.

The team should be taking on an understanding of the domain and accepting their part in ramping up in getting the product built. While there may be various questions initially, the team can ask the product owner for elaboration on the epics but the organization of the work and break down into tasks should definitely fall under the team's purview.

Improve this answer
1

The Product Owner shouldn't be putting 'epics' on the backlog, they should be putting stories on the backlog.

If, during the planning and estimation process the team finds that a story is too large to fit into a sprint, then the team promotes the story to an epic, and with the assistance of the Product Owner, breaks it down into manageable parts.

The important points:

  • POs don't get to write 'epics' in order to avoid thinking seriously about the features they want. They write stories that describe concrete features.

  • Breaking down a story into smaller pieces usually requires domain knowledge from both the development side and the Product Owner side. This is best thought of as a collaborative effort.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.