Scrum stories and behind the scenes features [closed]

Question

As I understand things, the Scrum backlog is composed of a series of Stories that represent something for the end user and this is further decomposed into Features.

If this is the case, where does all the behind the scenes features go that aren't really linked to a story but are still useful?

For example, say I'm making an application that catalogs the contents of a hard drive. A story wouldn't require it but having an md5 hash on each file would be a nice feature for flagging duplicates.

Flyback

there no such things as "behind the scenes features" in srum – Mog

Indeed. The way Scrum was presented, I thought there was only one backlog and it seemed pretty odd that some of the technical stuff should be there since it was difficult to link it with a user story. – Flyback

Answer 1

The classic template to write good stories is: "As a <role>, I want to <action> so that <business value>" (or variations around this) and a story should indeed provide business value. Why? Well, if a story does not communicate the business value it generates, how could a (very likely non technical) Product Owner evaluate its importance and prioritize it accordingly? Writing good stories increases your chances to get them rated as important and thus implemented.

A great tool to find good business value is the 5 Whys (which is used for root cause analysis, i.e. finding the root cause of a problem). The cucumber documentation explains very well how to use it to find some "good" business value and has a very good sample, so, instead of paraphrasing it, I'm quoting the explanation below:

Business value and MMF

You should discuss the "In order to" part of the feature and pop the why stack max 5 times (ask why recursively) until you end up with one of the following business values:

• Protect revenue
• Increase revenue
• Manage cost
• Increase brand value
• Make the product remarkable
• Provide more value to your customers

If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on implementing the MMFs (Minimum Marketable Features) that will yield the most value.

Here is an example taken from an IRC chat session in #cucumber:

[5:08pm] Luis_Byclosure: I'm having problems applying the "5 Why" rule, to the feature 
                         "login" (imagine an application like youtube)
[5:08pm] Luis_Byclosure: how do you explain the business value of the feature "login"?
[5:09pm] Luis_Byclosure: In order to be recognized among other people, I want to login 
                         in the application (?)
[5:09pm] Luis_Byclosure: why do I want to be recognized among other people?
[5:11pm] aslakhellesoy:  Why do people have to log in?
[5:12pm] Luis_Byclosure: I dunno... why? 
[5:12pm] aslakhellesoy:  I'm asking you
[5:13pm] aslakhellesoy:  Why have you decided login is needed? 
[5:13pm] Luis_Byclosure: identify users
[5:14pm] aslakhellesoy:  Why do you have to identify users?
[5:14pm] Luis_Byclosure: maybe because people like to know who is 
                         publishing what
[5:15pm] aslakhellesoy:  Why would anyone want to know who's publishing what?
[5:17pm] Luis_Byclosure: because if people feel that that content belongs 
                         to someone, then the content is trustworthy
[5:17pm] aslakhellesoy:  Why does content have to appear trustworthy?
[5:20pm] Luis_Byclosure: Trustworthy makes people interested in the content and 
                         consequently in the website
[5:20pm] Luis_Byclosure: Why do I want to get people interested in the website?
[5:20pm] aslakhellesoy:  :-) 
[5:21pm] aslakhellesoy:  Are you selling something there? Or is it just for fun?
[5:21pm] Luis_Byclosure: Because more traffic means more money in ads
[5:21pm] aslakhellesoy:  There you go!
[5:22pm] Luis_Byclosure: Why do I want to get more money in ads? Because I want to increase 
                         de revenues.
[5:22pm] Luis_Byclosure: And this is the end, right?
[5:23pm] aslakhellesoy:  In order to drive more people to the website and earn more admoney, 
                         authors should have to login, 
                         so that the content can be displayed with the author and appear 
                         more trustworthy.
[5:23pm] aslakhellesoy:  Does that make any sense? 
[5:25pm] Luis_Byclosure: Yes, I think so
[5:26pm] aslakhellesoy:  It's easier when you have someone clueless (like me) to ask the 
                         stupid why questions
[5:26pm] aslakhellesoy:  Now I know why you want login
[5:26pm] Luis_Byclosure: but it is difficult to find the reason for everything
[5:26pm] aslakhellesoy:  And if I was the customer I am in better shape to prioritise this 
                         feature among others
[5:29pm] Luis_Byclosure: true!

So, let me start: why would it be nice to have a md5 hash on each file (which, expressed as you did, is an implementation detail and doesn't communicate any business value)?

Bloodcurdling

"So, let me start: why would it be nice to have a md5 hash on each file (which, expressed as you did, is an implementation detail and doesn't communicate any business value)?" Good question. The md5 hash could be used to find duplicates. This is one feature I've seen in an existing cataloging utility. – Flyback

@James And why do you want to find duplicates? The answer to this question could be something like to clean a Hard Drive and save some disk space - which is valuable from a user point of view. And then your story becomes "In order to clean a hard drive and save some disk space, the catalog application should be able to flag duplicates so that users can decide what to do with them". This looks IMHO already much better than "have md5 hashes on each file", which is just a way to implement the "real" story (as a rule of thumb, technical stories are often a story smell). – Bloodcurdling

The 5 Whys are great but they are more targeted at Business Vision Document (Strategic Level) than at Product Backlog. Product Backlog is equivalent to Functional Specifications in other traditional methodologies that is it is something CONCRETE or Operationally Implementable not just a VISION. – Cecelia

@Rebol I disagree. In a nutshell, the 5 whys is just is a question-asking method, there is nothing that says it should be used for this or that, and nothing else (by the way, the 5 whys has been originally developed for problem solving, not to write a Business Vision Document). So I still think that the 5 whys is a very valuable technique to find the business value of user stories (and I'm well aware of what a vision document and a product backlog are). I'd be very interested to read references that you could provide though. – Bloodcurdling

I don't say that they could not be usefull I rather say it doesn't help much to focus on the main difficulty of creating stories: choosing the right granularity. – Cecelia

Answer 2

There is no "scrum" backlog, only

Product Backlog by the product owner that has Business Values

and

Sprint Backlog by the scrumaster/developpers which list tasks traced back to a story.

I am updating for precising the distinction between a Vision Document and a Product Backlog as for Business Value:

Business Vision Document (Strategic Level) are all about Business Value as well as Product Backlog. But Product Backlog is equivalent to Functional Specifications in other traditional methodologies that is it is something CONCRETE or OPERATIONNALLY directly implementable by the team not just a VISION from a high level managing director.

Of course product backlog itself should be tracable to Vision Document Items.

Cecelia

Ah, I didn't know about that. I'm still learning. Here's some links for reference. mountaingoatsoftware.com/scrum/product-backlog mountaingoatsoftware.com/scrum/sprint-backlog – Flyback

Answer 3

At the end of the day, agile is about doing what works for you to be productive. These kind of answers are for you to decide what works.

It may just be an implementation detail of another story, or it may be a story unto itself.

What ever makes your group most productive is what it should be.

Schafer

Answer 4

I would place them by something like:

• "Non user-stories" or "NUS"
• "Programmers Only" or "PO"
• "Behind the sences" or "BTS"

Followed by a short description of the feature.
So:

• BTS: catalog filesystem
• PO: find file type with magic bytes

_{Strange! I'm making the same application! :-)}

Update:

So, I read wiki, I think we need an extra log (the Sprint backlog).
Wiki says:

Sprint backlog

The sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice, tasks are normally estimated between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list.

Ornamented

all these should not even appear in product backlog because they have no business value. – Cecelia