0

Our shop is going to continue maintenance of a system in production already. Our next update consists of fixing a bug and creating documentation so that new members joining our team may understand the system. I don't know what the work items should be since we have a brand new Team Foundation Server (with Scrum template) and the higher-ups want all work tracked in it. Would something like this work?:

  • Epic: Customer relationship management "Echo" System Support and Updates.
  • Feature: System Updates.
  • PBI: 1. As a system admin, I want to understand the system completely so I can provide innovation and support.
  • Bug: 2. No role validation during approval of a product.
  • Task: 1. Create documentation with workflow process of "Echo" system.
  • Task: 2. Refactor code so that approval action will validate if role is correct for validation.
Improve this question
3
  • Ron Jeffries and Chet Hendrickson talk about user stories. A post by Ron Jeffries in 2001.
    – Alan Larimer
    Commented Apr 6, 2018 at 12:27
  • I saw and read your links - it seems to be substantiating the idea of being flexible with stories but still keeping the who, what, why questions answered. He joked about the "As" format, but he still ended up confirming it needed to answer those 3 Ws. However I'm more interested on how teams track their work that is not directly a business value\product owner related, such as creating documents, training, new employees etc.
    – BrooklynSon
    Commented Apr 6, 2018 at 13:16
  • Only work directly related to the product should be tracked in the tool. Using it as a complete worker time tracking solution is not the purpose. Also beware the 100% utilization fallacy.
    – Alan Larimer
    Commented Apr 6, 2018 at 13:41

2 Answers 2

Reset to default
1

You haven't said how long your sprint is, and with only a couple tasks the burndown chart is not going to give you or the stakeholders a lot of information. If you can do this in a couple days as a part of a technical debt cleanup sprint, I think it's probably fine. If not, see if you can break the tasks down into 8 hour or less work packages.

Hope that helps

Improve this answer
3
  • The sprints are 2 weeks long, the program increment is 2 months long. As far as the work is concerned that bug was finished in an 2 hours - the requirements documentation is taking about a few business days.
    – BrooklynSon
    Commented Apr 5, 2018 at 16:10
  • Ok, so at less than a week total it probably was just a part of the sprint. I think you are fine then.
    – Gregory Morton
    Commented Apr 5, 2018 at 16:19
  • OK I was worried that my PBI didn't really add any "business value" and hence it wouldn't be good the way I had laid it out.
    – BrooklynSon
    Commented Apr 5, 2018 at 16:24
0

In Scrum a common approach is to wrap everything around user stories.

Taking your examples:

As a system admin, I want to understand the system completely so I can provide innovation and support

This isn't a user story, it is a task that could be incorporated into a story that delivers business value.

A more Scrum approach would be to have:

As a user I want the approval action to validate if I have the correctly validated role so that I can complete all required approvals

There could be several sub-tasks under this story, including:

Gain an understanding of the system

Create documentation for the system

The idea is to focus your backlog on delivering business value, but that does not mean you ignore the tasks required to deliver that work. You simply wrap it in to the user stories.

Improve this answer
2
  • Thank you Barnaby, it seems I always get two very polar answers for User Stories, some say it's only for Business Value, some are more flexible by using alternative stories such as "As a system admin,...". Even on google searches I get different answers, it's seems to just be a style approach.
    – BrooklynSon
    Commented Apr 6, 2018 at 12:07
  • It is probably best to do what the team and Product Owner feel most comfortable with. It's worth noting that making work items sub-tasks of stories doesn't make them any less important. In some ways it emphasises how important they are: we NEED to understand and document the system as it is critical to delivering business stories. It stops there being a conversation where it is suggested that understanding/documenting can be delayed while business value is delivered.
    – Barnaby Golden
    Commented Apr 6, 2018 at 16:41

Your Answer

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

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