We are using Visual Studio Team Services (VSTS) to manage work items. VSTS uses a hierarchy of Epic -- Feature -- User Story -- Task. It is clear that the individual software engineer owns a 'user story'. Currently, our team is also assigning the 'feature' to a software engineer as well. The feature is a container or parent for several user stories and the different user stories could be assigned to different engineers. Should the software engineer be responsible for the 'feature' or should it be the product owner (PO)?
1
-
To add to nvoigt answer and as per the Scrum guidelines, the Product Owner owns the Product Backlog Items(user stories, epics, features..) but manage it in collaboration with the development team. The development team owns and mange the Sprint Backlog Items (User Stories and their Tasks).– Amo A.Commented Jun 3, 2018 at 10:15
Add a comment
|
2 Answers
It is clear that the individual software engineer owns a 'user story'.
Let me be clear, we are not talking about Scrum here. We are talking about how to best squeeze Scrum into the ticket management system with templates that VSTS is. In Scrum, if anybody, the development team "owns" a PBI (for example User Story) in the sprint backlog. Multiple individuals can work on the item at the same time and the whole team owns it collectively. VSTS cannot do this, but the field is mandatory, so you need a workaround. Don't assume your workaround is the norm or Scrum, it's not, it's a legacy from command&control project management that VSTS cannot hide. Many other systems have that problem, too.
So what is the best workaround for items higher up the hierarchy? I'd say it's the product owner, because only they can influence the status. A feature or epic is done when all stories are done, so there is nothing the team can do about that. The PO decides when those come into a sprint to be worked on.
The presence of the 'Assignee' field in Jira lowers velocity by completely destroying teamwork -Jim Coplien
This reflects my own experience! Team assigns an item to a person, person becomes accountable for that item. Feels a lot like favoring tools and individuals over interactions!
The whole Team is accountable for delivering the Increment and achieving the Sprint Goal. If a Developer doesn't know which pair/swarm/person is working on an item then they probably weren't paying proper attention at the Daily Scrum.
My advice would be to leave it blank. If it is mandatory in your tool then create a dummy user (e.g. Jerry Gergich); if it must be a real person then pick the most unlikely person. But alwasy use the same person so that no one gets the idea that a single person can be accountable for an item.
-
1If you make a dummy, just call it "Scrum Team" or something like that.– ErikCommented Jun 10, 2018 at 18:11