At what Work Item level does the Product Owner prioritize in TFS?

Question

Our team is reviewing our Agile process while we look at moving to Kanban style flow instead of Sprints. One question we are having a hard time answering is

At what level (what type of Work Item) should the Product Owner be prioritizing at?

In our mind, it comes down to either Feature or User Story (Bug). However, no matter which one we choose, we are seeing scenarios where it would cause problems.

User Story

Our understanding is that the developers always work at the User Story level. (Yes...they also can work at the Task level but the highest point is Story.)

That implies that the Product Owner is submitting and prioritizing User Stories and Bugs.

However, it is possible that a develop would break up a User Story into multiple stories due to scheduling, division of work with other developers, or some other reason.

In this case, the Product Owner may not care or even become confused with the appearance of these seemingly unrelated Stories on the board.

Feature

Alternatively, we could have the Product Owner work at the Feature level, while letting the developers continue working with User Stories.

This means that the PO is submitting and prioritizing Features. It would also allow the developer to create more than one User Story without the PO potentially getting confused.

The problem with this approach is handling Bugs. Since bugs appear at the User Story level, how would the PO properly prioritize on the two different Boards? I guess the bug could be entered as a Feature (with a child Bug also existing) but that seems wrong.

Functionality Group

This section could probably be submitted as a separate question but I have added it because my 2nd approach exposes the problem...

Maybe "Feature" is the wrong word used in TFS, but in my mind a Work Item Feature would be "particular functionality in an application". For example, a Feature titled "The ability to sort search results". Example, User Stories under that could be "Sort by Id field" and "Sort by Last Modified field".

Assume that this piece of functionality is rolled out and then some time later, an enhancement titled "Sort by Name" is submitted. Should that be submitted as a new Feature? If so, how (and should it) be related to the original Feature? Or should it be submitted as a User Story related to the original Feature causing the now closed Feature to be reopened?

How does this affect bugs? Should a Bug be associated with the original Feature?

Would Epics come into play in any of this?

Answer 1

This question transcends TFS, or any other development tool like Rational Team Concernt (IBM) or JIRA (Atlassian) just to name a few.

---

The Product Owner is the "Big Picture" person and should be prioritizing Epics. One you get down to the Story level, dependencies on functionality start driving priority. Take for instance an agile project that is building a blog.

You could have the following Epics:

• Writing blog posts
• Commenting on blog posts
• Sharing blog posts

The first epic, Writing blog posts needs to be worked on first, because you can't comment or share something that doesn't exist. So that's the easy one. The Product Owner needs to decide which of the other two epics are more important after that: Commenting or sharing.

After that decision gets made, let's say the Product Owner ends up with this:

1. Writing blog posts
2. Sharing blog posts
3. Commenting on blog posts

Ok, so sharing blog posts is more important. What is required to do all this? Well, you break it down into stories:

1. Writing blog posts
   • Add a new blog post
   • Update an existing blog post
   • Delete a blog post
   • Show a blog post
2. Sharing blog posts
   • Share on Social Network A
   • Share on Social Network B
   • Share via e-mail
   • Share via permalink
3. Commenting on blog posts
   • Add a comment
   • Flag a comment for abuse
   • Delete a comment
   • Moderate a commentt

If we just focus for a moment on the first epic, adding blog posts. We have 4 stories that basically revolve around the CRUD operations in the database. The priority of these stories starts to become clear. You can't view, update or delete something until it's created in the first place, so adding a new post is #1. Showing, updating and deleting a blog post only relies on adding a blog post. What is the development team supposed to do?

Have the Product Owner tell them which one they want next.

1. Writing blog posts
   1. Add a new blog post
   2. Show a blog post
   3. Update an existing blog post
   4. Delete a blog post

Prioritization happens on two levels that require input from the Product Owner:

• Epics to see the Big Picture
• Stories to support the Big Picture and drive for the Minimally Viable Product

The Product Owner should prioritize Epics. At the Story level you start to see dependencies arise between stories. This assists in prioritizing stories for the development team (you can't view something before creating it). Other stories with simple or no dependencies should be prioritized by the Product Owner.

Answer 2

I would say prioritization should clearly happen at User Story level. A user story is (for me) the minimum viable implementation that is visible and (typically) useful for the product owner (if it is more than the minimum, consider vertical splitting).

User story splitting during development makes only sense when the resulting pieces are still useful for the product owner. Otherwise, the pieces should be Tasks.

Also, prioritization at the user story level allows the product owner to get some significant parts of a feature much earlier than the rest - he can look at multiple features simultaneously, and pick some small user stories from each to get the biggest bang for the buck right away.

Note: this is what I understood from my trainings, and how we handle it - successfully - for years. It is not necessarily 'the officially agreed way to do things', but then Agile means to me that every team can adjust the process as it sees fit for it, so there shouldn't really be an 'officially agreed way'.

Answer 3

Whether using TFS, Jira or any other tool that simply provides a container for the user stories, the Product Owner and the stakeholder management team can prioritize at any level in the Backlog based on the needs of the organisation at that point. So they are not restricted to ordering Epics only or User stories only but they would spend more time ordering user stories as that is how they drive value and they are more granular and detailed than Epics which likely will not need to be updated as often as the user stories.

Product Owners should not prioritize the tasks attached to the user stories because the tasks are created and owned by the development teams doing the work and they know best what needs to be done and how to do it in order to deliver a user story.