3

I'm trying to figure out when using user stories is appropriate. Always or not?

For an example, think about a team starting to work on something from scratch, say a movie ticket reservation service. It's easy to come up with user stories for the functionality, like: "As an end-user I want to be able to browse the movies running in theater X" and so on.

But before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic.

How should these tasks appear in the backlog? Should they be user stories as well? If so, how do they comply with the INVEST mnemonic? They don't alone deliver anything for the end-user, but nevertheless they are needed before any feature can be implemented.

wannabeartist
  • 2,753
  • 6
  • 36
  • 49
  • 2
    Closely related: http://stackoverflow.com/questions/2795733/scrum-stories-and-behind-the-scenes-features?rq=1 and http://stackoverflow.com/questions/1707080/writing-user-stories-for-internal-technical-tasks?rq=1 – Thilo Nov 02 '12 at 07:39

2 Answers2

4

But before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic.

Not really agree with it. Since a story is a feature which takes almost every layer of your architecture implementing the story builds up the architecture same time. Check up Alistair Cockburn's Walking Skeleton definition.

About the question

Most of the stories you may define as "As a user..." as a feature the story may has UI work as well. So to make it clear you may split up the story into subtasks. Although some work would be hard to present in INVEST user stories. For instance bugs, tech. dept and so on. They still be presented as stories of a special type(Bugs, tech stories). you couldn't show them on Demo however you may mention about.

Arseny
  • 7,251
  • 4
  • 37
  • 52
  • That walking skeleton idea is cool, but I find it hard to see how it would work with a real-life, reasonably big and complicated software. I would find it very hard to implement a feature without first having an idea of "how it all plays together" – wannabeartist Nov 02 '12 at 10:28
  • 2
    Right. Sometimes we have to come up with some design. May be at zero iteration. However it's no necessary to polish it up to make it perfect, instead, every story which take that architecture will change and polish the design. – Arseny Nov 02 '12 at 12:57
1

(...) before those can be implemented, the system needs to be designed: Architecture must be designed, database must be designed, technologies chosen for the GUI and business logic. (...)

Not exactly. E.g., you don't need to get the entire database designed for implementing functionalities for a sprint, a specific release or whatever given time. What you may need is some common ground.

This is where one of the Agile's beauties lives (vs. waterfall), welcoming change.

Now, answering your question: realize that the role in a user story is not necessary a role of the end customer. Could be your developers, your sysadmins, etc. As such:

AS A server administrator,
I WANT to upgrade our webserver
SO THAT it will handle better the memory consumption

So, you could ask convince your P.O. to add or prioritize in the backlog an user story (or several) for building up some ground for the future development. But, again, when creating such stories remember the Agile value of Responding to change.

P.S.

It's also important to keep the Product Backlog clear and accessible, and provide properly interaction between P.O. and Development Team. This should be guided by the Scrum Master.

This way the team could give better feedback/warn the P.O., in a technical perspective, how one story affect each other and why should story X should be done before story Y.

talles
  • 14,356
  • 8
  • 45
  • 58
  • (about roles) I have asked around and indeed it seems that this is the way it's usually done. However, there are some conflicting articles, like: http://www.scrumalliance.org/articles/366--common-mistakes-we-make-writing-user-stories *** see "3. User Story for Developer" – wannabeartist Nov 08 '12 at 06:24
  • 1
    @wannabeartist the ideal is to bound technical needs to user stories that represents value for the customer (e.g. refactoring the search SO THAT the search is faster), but sometimes you just can't. In this case make sure that the other stories of the sprint does represent value to the customer.It is critical when you have a whole sprint with no or little value to deliver to the customer. – talles Nov 08 '12 at 20:23