1

We are taking our first steps in agile and Scrum. We use VersionOne for managing our user stories and tasks.

As the development manager, I am trying to build a sprint plan for the development team. Now, VersionOne is fine for tracking user stories, but not all work is currently organized into user stories. For example: escalated support tickets, ongoing bugs, training new employees, and researching future technologies.

My problem is that I want to merge the user-story work plan that VersionOne gives me with the other tasks that the team has. Placing the items mentioned above in the backlog seems unnatural. On the other hand, managing them someplace else means I will either duplicate the VersionOne information in the other system, or I will have two systems tracking the development tasks.

How can I manage both user stories and other non-backlog tasks?

  • 1
    A user story is just a format for work items. Why can't you write user stories for your bugs, training, and research? They belong on the Product Backlog, too. – Todd A. Jacobs Sep 6 '13 at 9:08
  • @CodeGnome Do the really? Shouldn't backlog items have a measurable contribution to the shipping product (I.e. shouldn't they be "features")? Training does not fall into this definition. As for bugs - there are many of those, and many of them are very small, so we usually allocate a bulk time slot for bugs. Customer cases are handled similarly. As for research, my problem with adding it to the backlog is that it is dev-driven rather than product-driven. As I said, we're just starting with agile so we may be looking at this wrong. – TaskTracker Sep 6 '13 at 10:13
  • 1
    Work is work. See pm.stackexchange.com/a/6513/4271, pm.stackexchange.com/a/8618/4271, and pm.stackexchange.com/a/8682/4271 for some related answers on that topic. – Todd A. Jacobs Sep 6 '13 at 14:04
  • @CodeGnome Thank you for these insightful links! – TaskTracker Sep 6 '13 at 18:01
0

VersionOne uses the concept of Backlog Items:

This generally represents a valued functionality that can be estimated and tested, but may also encompass non-functional requirements and defects.

Stories are mainly features but can also be any other task that helps the team in delivering value to the customer.

If Scrum is being followed then your team should not perform any task that is not part of the Sprint. All tasks done by the team should be documented and accounted for. One of the strong points of Scrum methodology is visibility and transparency of the process. If project delivery requires some research, add a new Backlog item and track it appropriately. If there are defects to be fixed, a new Backlog item is needed. If there are minor bugs, they can be grouped and tracked as one defect.

  • Interesting view. Would you say that training new employees also fits there? Sounds like you would, but it seems forced to me. There are no "acceptance test" or requirements here. Also, the training task (like research tasks) are defined by dev and not by the product owner. Our product manager has explicitly asked that we (dev) not create user stories.. – TaskTracker Sep 6 '13 at 13:48
  • Interesting view. Would you say that training new employees also fits there? Sounds like you would, but it seems forced to me. There are no "acceptance test" or requirements here. Also, the training task (like research tasks) are defined by dev and not by the product owner. Our product manager has explicitly asked that we (dev) not create user stories.. – TaskTracker Sep 6 '13 at 13:48
  • 1
    Your product owner is right, Product backlog is owned by the product owner. However, everyone can provide input for the Product Backlog, it will be up to the PO if he/she wants to add that new piece to the Backlog or not (is the PO convinced that the new piece will really add value to the product or not). In agile world, 'research stories' are called Spikes which also go into the Backlog. Trainings would be a gray area, I think. If it is an on-going event (across the company) then it would not go into your Backlog. However, if it is project specific then it may become a backlog item. – Aziz Shaikh Sep 6 '13 at 13:58
  • The training is neither company-wide no. project-specific. A new developer has just joined the team and he must be trained. This obviously requires resources. How would you manage it? – TaskTracker Sep 6 '13 at 14:01
3

TL;DR

In Scrum, all work chargeable to the project belongs on the Product Backlog. This includes bugs, training, and research in addition to features.

User Stories Recommended, Not Required

A user story is just a format for work items. While it is a widely-accepted practice to formulate user stories for placement on the Product Backlog, Scrum doesn't constrain the format.

From a process point of view, there is nothing preventing you from reformulating the additional work items as user stories and submitting them to the Product Owner for insertion into the Product Backlog. At that point, the Product Owner can manage those stories just like any other story in terms of prioritization and scheduling.

Non-Feature Stories

CodeGnome's Law of Transparency says "No invisible work, ever!" That means that:

should all be managed from the Product Backlog. Not adding them to the Product Backlog results in hidden costs to the project and work that is invisible to the organization; this is antithetical to the agile tenets of Scrum and may undo many of the benefits you hoped to gain from adopting the Scrum framework in the first place.

0

We run a separate swim lane at the top of our Scrum board for the 'day-to-day' bugs and tasks that unexpectedly come in, and are urgent. If these are significant, they will be discussed to ensure they will not compromise delivery of the sprint. Generally they are small (up to 1 hour) jobs that will not have a noticeable impact. If they are not urgent, they are added to our backlog for allocation to a future sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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