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

Question

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?

Answer 1

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.

Answer 2

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:

• bugs and chores;
• non-functional requirements;
• team or organizational training;
• research spikes; and
• any other effort that consumes project resources

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.

Answer 3

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.