0

This question could be similar to At what level should the Product Owner prioritize work?. However, I ask questions based on specific use cases that is not addressed there.

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?

Improve this question
1
  • 1
    Please do not crosspost. That said, my comment there is still valid: you did not say which method you are following. Without that, we could only give you a bag of opinions, which the SE network frowns upon.
    – nvoigt
    Jul 12, 2018 at 9:43

1 Answer 1

Reset to default
1

I think there may be some confusion between what is a feature, what is a story and what is a task.

Using your example, I would expect something like this...

The Product Owner is working on the search feature. They add several user stories to the backlog:

As a standard user I want to be able to sort search results by Last Modified Date so that I can tell which results are recent

As an admin user I want to be able to sort search results by ID, so that I can complete the resupply list

The team might take these user stories and break them down in to a number of technical implementation tasks, such as:

Add last modified date to the database and index it

Create a web page that presents results

Create some dummy data for testing

The Product Owner does not care about tasks, but they do care about user stories as they provide a clear benefit to the users of the product. They want to report on the progress of user stories to their stakeholders.

It is not unusual for the Product Owner and the development team to work together in breaking user stories down. The development team might prefer smaller stories as it helps them with scheduling and division of work. However, you would not expect the development team to be creating user stories without the involvement of the Product Owner.

A summary might be:

  • Feature: A grouping of one or more user stories that are associated with a particular feature in the product
  • User story: Something that provides end user benefit and written from the point of view of the end user
  • Tasks: Technical implementation activities that come together to deliver stories
Improve this answer
2
  • 1
    BG is spot on with his post. I don't want to add an additional post but I would add how I coach teams. "A task something only you are interested in. The User Story is what can be demo'd to a non-technical stakeholder and they can understand it." If I, as a PO, add a User Story to the backlog and Devs then decide to break it down into multiple tasks..that is fine. Let me know when the story is done. If they decide to split the story using a story splitting pattern (Logic, CRUD etc) that is also fine. Just let me know and ensure all are estimated.
    – Venture2099
    Jul 13, 2018 at 7:18
  • If they want to do 1 story this sprint and 1 next sprint..OK. Maybe. Let's talk about it. Everything is a conversation.
    – Venture2099
    Jul 13, 2018 at 7:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.