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

Question

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?

Answer 1

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.

Answer 2

I don't think the problem here is Scrum as such, I think the problem is that there isn't a clearly defined project deliverable and (I've experienced this many times) no clear direction.

I think your technical tasks are fine, possibly on the large side but measurable and definable so absolutely fine for a story.

Research tasks are a huge red flag for me in Scrum because they provide little visible benefit and can create enormous scope creep. I advocate limiting these upfront in a sprint, they should not be added in and they certainly shouldn't be added in at the expense of committed goals. If they're needed to complete an agreed sprint task then that dependency should have been clear at planning (otherwise, what were they estimating?).

In my experience, projects with lots of "investigation spikes" are a cover for developers not actually doing a great deal and wanting to spend time finding out about the new shiny cool thing rather than creating business value. I'm not suggesting your team is doing this, but a project needs clear goals and if developers are given freedom to "research" then they'll do it, and keep doing it, for as long as you'll allow it.

Answer 3

Scrum says that you'd better have a deliverable product to your customer. However, the point here is that, it doesn't specify the deliverable product and the customer.

In other words, in your specific case, you might define your deliverable product as code improvements, platform changes, rewrites and redesigns, etc., and consider your technical manager to be your customer.

That makes 100% sense to me. You create a backlog that tells the stories of the user of your products, and who is the user? Technical manager. Thus items like:

1. As the technical manager, I want my database to change from MySQL to X, so that I can increase the scalability
2. As the developer, I want a comprehensive logging system, so that I can diagnose more efficiently

And what you deliver to your customer (technical manager) is a logging system.

However, regarding the R&D tasks you talked about, I recommend that you read about spikes in Scrum. They are essentially time-boxed mini-tasks that help you determine the time required to perform bigger unfamiliar tasks.

Answer 4

As the Scrum Master, you may want to consider longer sprints because of the nature of the work. This will give you a little more of a buffer for the "research" tasks. However, I think you need to make sure the tasks produce some sort of work product/proof of concept in code. Whatelse do you expect a programmer to do? Ask them to get something to work and use this information to determine if A: it does what we want B: it performs better C: How long will it take to get more up-to-speed and start getting any idea how long it will take to make something.

If you discover you don't know as much as you thought about the current rewrite, you can go to shorter sprint cycles. Don't be afraid to adjust them as you go along; this is what is meant by being agile. After your research you may also decide to go with the new technology. This could be another reason to shorten the sprints before getting too far out of control. You may discover in the middle of a sprint the new stuff isn't going to work. Stop the sprint and adjust it with the old technology. Afterall, your developers should have been able to compare and contrast the old and new methods.

You're juggling the needs of your developers and in this case getting the application rewritten. I'm guessing there are Product Owners who want this project completed sooner rather than later and won't accept the need for "research" as a long term excuse.

Answer 5

Some of the below strategies may help,

1. Yes, you can Have a backlog with with Technical stories.

   Like a user story this also should be Technical Stories, focusing on the benefits it will be bring to the end user. Here is some tips writing it. These are stories which will bring intrinsic value to the product like you want to move to a better back-end etc.

2. For Investigation (Research) Tasks Use Spike

   A spike is an experiment that allows developers to learn just enough about something unknown in a user story, e.g. a new technology, to be able to estimate that user story. A spike must be time-boxed. This defines the maximum time that will be spent learning and fixes the estimate for the spike.