4

If You've seen Hitchiker's guide to the Galaxy, you know that Deep Thought (pictured below) is a machine that was built to compute the meaning of life:

Deep Thought

Let's imagine that we were tasked with building this machine using Agile Scrum, and to use User Stories.

There really only appears to be one Story, which is: "As a user, I want to know to the meaning of life, so that I know why I exist"

The machine is imperceptibly complex and will take a very long time to build (more than would fit into one Sprint), so we want to split our one User Story into smaller User Stories that will fit into our Sprints.

In true Agile, we would split the User Story into smaller User Stories that would create a vertical slice through the Deep Thought system. However, in this case it seems the user Story can't be broken down into anything smaller as it is already the smallest (and only) thing the user wants from the system, in which case a vertical slice is the entire system. We can't deliver anything of use to the user until the entire back-end system is complete. Okay, we could build the shell and deliver that, but from then until the internals are complete the user would see no difference.

We could however split the user Story into Technical User Stories which describe back-end features to be created to support our User Story, but this creates horizontal slices in the system and is frowned upon by true Agilists.

The reason I'm asking is because I'm tasked with creating a system that can be described in the same way as above - a large back-end system with a single entry-point that will take a long time to implement before any response (other than by a stub) can be made to that entry-point.

So, how can we break down "As a user, I want to know to the meaning of life, so that I know why I exist" into backlog items?

Improve this question
8
  • 6
    I voted to close as Too Broad. Oh, the irony.
    – Robert Harvey
    Jul 26, 2016 at 16:16
  • 4
    On a more serious note, post your actual problem (if you can), rather than this unanswerable hypothetical.
    – Robert Harvey
    Jul 26, 2016 at 16:17
  • 2
    Also, if Technical User Stories will help solve your problem, I don't really give a shit whether the True Agilists™ approve or not.
    – Robert Harvey
    Jul 26, 2016 at 16:20
  • 2
    @RobertHarvey: It's a fair point you made, actual details would be very useful. I was hoping to get a more high level, abstract view on how to approach this kind of system in general instead of a specific answer to my actual system. I generally tend to find that more useful, and I thought Deep Thought was a good analogy.
    – parrowdice
    Jul 26, 2016 at 16:30
  • 1
    Is a "true agilist" anything like a true scotsman? A true agilst doesn't stick to dogma, a true agilst does whatever it takes to get the job done.
    – Bryan Oakley
    Jul 26, 2016 at 16:54

2 Answers 2

Reset to default
2

Since there is no such thing as a "true agilist", I'll make up my own definition.

A "true agilist" knows that a larger story is composed of smaller stories. Agile practices teach us to relate these stories to users, and to break down these stories into smaller and smaller piece until we end up with individual pieces that can be completed within the bounds of a sprint.

It doesn't really matter if the stories are user stories, technical stories, front end stories, back end stories, vertical slices, horizontal slices, etc. The point is to break a large job into a series of smaller jobs, prioritize those jobs according to the needs of the user as much as possible, and then work on those jobs while getting constant feedback along the way.

Stories should be associated with users. If you are building a black box, then the customer isn't really the user. The real user for your user stories is the team that is delivering the box.

The customer needs a UI in which to submit the question and get the answer. The UI developer needs an API where she can submit the question and retrieve the answer. The API developer needs a back end to talk to. The back end developer needs a database to store knowledge. The testers need an API so that they can test the software. And so on.Your stories need to address the needs of all those users.

Improve this answer
4
  • That's an interesting concept I hadn't thought of - thinking of internal layers of the system as users themselves...
    – parrowdice
    Jul 26, 2016 at 17:40
  • Did you answer the question that was asked?
    – Robert Harvey
    Jul 26, 2016 at 17:48
  • @RobertHarvey: I think I did. The question is "how do we break down stories", and the answer is to not look at the customer as the only user, but to break down stories for the various stakeholders tasked with delivering the product.
    – Bryan Oakley
    Jul 26, 2016 at 18:08
  • 1
    "It doesn't really matter if the stories are user stories, technical stories, front end stories, back end stories, vertical slices, horizontal slices, etc" -- it doesnt matter as long as you are delivering value on the way!
    – Dave Hillier
    Jul 27, 2016 at 9:06
2

This generalising, abstract thing is distracting you. Agile will teach you very quickly to become pragmatic. There is more to be learnt by taking on problems in small parts that are highly specific. Once you grok each part, the repetition of this process will help you learn the process and build domain knowledge at the same time, thus progressing you to bigger and bigger fractions of the whole as you rack up more and more of these small pieces.

You could have described your "large back-end system with a single entry-point" far more exactly without making an analogy.

I think reading into your "vertical slice" narrative, you're attempting to create something like an MVP epic to begin with. You have my applause for this intention. It's very characteristic of a lean startup and something I've also done in the past.

The purpose of an MVP is learning: to test the riskiest assumptions ("de-risk" them) and validate those core elements. So the next step is to break this large idea down into the assumptions. Since this is so freaking vague and hypothetical, I'm going to make some assumptions of my own for the purpose of demonstrating this "breaking down" process. Here we go:

  • The value part of As a user, I want to know to the meaning of life, so that I know why I exist is "so that I know why I exist".
  • "so that I know why I exist" answers the broad and very 'root' philosophical question "Why do I exist?"
  • If "Deep Thought" can answer the root question "Why do I exist?", it's logical to assume it can answer far more derived and specific questions, like for example "What is 1 + 1?"
  • Can we define a vertical slice as "As a user, I want to compute basic arithmetic, so I can validate my arithmetic understanding"? (or something similarly nonsensical)
  • Maybe it's not a complete vertical slice of all the complex internals for the root computation, however it will test out the query input system, the result/output delivery system and some arbitrary infrastructure to model the capture of a query/request and some of the processing pipeline (maybe)
  • So let's say our epic is As a user, I want to compute basic arithmetic, so I can validate my arithmetic understanding and our first story is As a user, I want to evaluate 1 + 1, so I can verify basic arithmetic. Boom! you now have something concrete and explicit you can even write an end-to-end test for (maybe)

You may still want to break this story down into user flows around the input, output, etc as you discover more. But this discovery process is facilitated by the discussion you have like this (these bullet points). As you force yourself to brainstorm and cut things up, you discover more about the domain and details materialise. Things become concrete and explicit, or at least you force them to.

By the way, this is also wrong: "We can't deliver anything of use to the user until the entire back-end system is complete".

Just like a business can build a facade to an automated system by using the concierge service technique, you too can do the same and still deliver value. If your "1 + 1" story eventuates and you have some sort of automated test that asserts the result "2", you can implement this using static code to pass the test right? (Think TDD.) It doesn't even need to use a binary operator initially.

You can totally deploy this to production and show the 'user' how the product (Deep Thought) can reason and produce a result from a very specific query. You don't have to say it's "hard coded". You're trying to test assumptions in an agile manner and capture the feedback in a tight loop.

This is what agile and lean are all about: capturing learning as fast as possible. This is made possible by as small a batch size as possible. The result of this process is as little waste as possible.

Improve this answer
1
  • I can't really beat this answer, so I'll just add a link which gives some more detail: mountaingoatsoftware.com/blog/… - make sure to read through the QA section at the end, with specifics for different scenarios. PS I came across this Q while trying to find a more up-to-date answer than the 10 year old article I've linked to.
    – Adam
    Jan 4, 2017 at 12:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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