Can Scrum use technical specifications in the Product Backlog rather than user stories

product-backlogproject-managementscrumuser-story

At the company I am currently working for we started to do Scrum projects. It was not so hard to convince the managers to move from waterfall to Scrum. We're doing a project where we rebuild our platform from scratch. So (most) functionality is known and most improvements are rather technical.

In this it could be justified to have technical tasks rather than user stories. Our backlog has got all kinds of technical tasks like:

  • Rewrite DB class from MySQL to PostgreSQL.
  • Implement system logging.
  • Rewrite object cache.

Things that come up during the stand-ups include that long "research tasks" are wanted, but they are never done. Also, the team members claim in the middle of the sprint that unplanned tasks need to be added.

How should a Scrum Master deal with this? Could it be that for this kind of project, Scrum is NOT the way to go?

Best Answer

TL;DR

Scrum does not mandate the use of user stories; they are simply a useful agile practice. While the Product Owner could certainly use technical specifications instead of user stories to build the Product Backlog, most of your other process problems stem from a failure to embrace effective Scrum and agile practices.

Various Problems with Your Process

Your Scrum appears to be broken in a wide variety of ways, including:

  1. Your specifications lack an explicit point of view or value proposition.
  2. Your backlog items aren't being tied to Sprint Goals.
  3. Your Backlog Grooming process is either missing altogether or failing to create story spikes for the Product Backlog.
  4. Your Sprint Planning process is not adequately decomposing Product Backlog items into Sprint Backlog items.
  5. Your team is not properly including uncertainty about backlog items in its Sprint Planning estimates.
  6. Your team is not respecting the fundamentals of time-boxing or the integrity of the Sprint.

While Scrum is not always the right fit for every project, in this case it would be more accurate to say that Scrum isn't working because the team isn't really doing Scrum. Your question about user stories is only a small part of the larger process issues facing your team.

Why Agile Programmers Embrace User Stories

Technical specifications are a fundamentally broken way to communicate requirements. Requirements that are unmoored from a point of view don't provide any useful guidance for developers. Using your posted examples:

  • Rewrite object cache. Why? What's the objective? Who receives the benefit? Who can provide clarification about the task? If this is tied to a non-functional requirement, what project goal does this address?
  • Implement system logging. Why? Who's going to read the logs? What information do the logs need to contain? How will you know if the log format or log data are useful?

From a developer's perspective, not being able to answer these sorts of questions leads to exactly the sort of process problems you describe. That's what user stories do: they provide much-needed context and act as placeholders for additional conversations with stakeholders or end users about specific features.

You shouldn't use user stories because you think it's a framework requirement, or because it's a widely-accepted agile practice. Instead, you should work on creating and using them effectively because it makes programming tasks easier and the programming profession more fun. Your mileage may vary, of course.

Related Topic