What comes between the vision and a product backlog in scrum? [closed]

Question

Not looking really for a book. I have seen lots of references and links to them. I can't buy one right now. I have been reading online, watching videos, etc. One thing so far I don't get. What comes between the vision (solution to the problem) and the product backlog. From what I read, I think it is user stories but I am not sure.

Is there anything online that shows all the steps in a linear fashion from vision/concept to the end?

Thank you for any direction.

EDIT: On the requirements gathering, just use Excel?

Answer 1

User stories and a lot of negotiation over what's essential and what's fluff.

A lot of negotiation.

Also a lot of back-and-forth on architecture. Scrum requires a stable, proven architecture. However, there are always upgrades and enhancements. How do those fit with the backlog? That's a lot of political jockeying between product owner, technology folks and (to an extent) users/buyers.

The process in inherently non-linear.

It's more like crystallization. You have a solution, you start to write stories, you have a technology vision, you have a team with certain skills and experience.

Any one of these features can serve as a "nucleus" for deciding what goes into the backlog and in what order. Eventually, something becomes the nucleus and the mixture crystallizes. Sometimes the cost or schedule or risks are unacceptable, so you heat it back up, find another nucleus and see if it crystallizes acceptably around that new nucleus.

The recrystallization happens after each sprint, by the way, making it even less linear.

---

Edit. "stable proven architecture".

Question: Who pays for learning the new architecture?

Answer: Ha ha. There's no good answer. So be careful how much architectural learning you do while you have development sprints going on.

If you don't have an architecture in place that (a) works, and (b) can be articulated by almost everyone on the team, you're going to spend time assembling that architecture.

What does the time and cost of creating an architecture do to your first sprint?

You have to incorporate architecture development into the first sprint, delaying things.

Let's say you decide to implement a LAMP stack. You don't know whether to unix PHP, Perl or Python. So you pick one. Like Python. And you promise the first sprint in four weeks. So you work for 3 weeks struggling with the kabillion add-one modules and frameworks. After 3 weeks, you think you have a working tech stack, but you don't have the promised sprint.

Do you delay? If so, everyone asks if you've got the pace right and starts doubling the time for all other sprints.

Do you deliver nothing? If so, what's the point of sprints if you have nothing at the end except infrastructure?

You can change, modify and enhance the infrastructure -- in manageable pieces. But to build a fresh architecture, prove out the pieces, train everyone and develop best practices takes time. A lot of it. And that time shouldn't -- really -- be charged as sprint time creating deliverable product. That's overhead time.

---

Edit. Tooling.

Rule 1. Agile processes don't use a lot of complex tools and processes. That's why I said that the process is a lot of "negotiation". Whatever makes you productive.

Rule 2. Don't over think it. Just do it.

Most folks say -- in the strongest possible way -- use 5"x8" paper cards and stick them to a wall. Seriously. No tools. Just simple paper, markers, tape and blank wall space.

Read this: http://www.agilemodeling.com/artifacts/userStory.htm

You can use a spreadsheet to collect user stories (and epics -- stories that have to be decomposed). You can add columns for complexity (story points), cost, priority and release, and use it for project management.

We use use cases (not user stories) but the tooling is the same. A use case is -- in a way -- a user story with more details up front. But the use case name can summarize how an actor interacts with a system; the interaction can usually be summarized with clear, simple nouns and a verb, which is very much like a user story.

Spreadsheets seem handy because you can rearrange the rows at the end of each sprint. You can do simple counts and sums to work out how much each feature will cost and when they'll arrive.

I don't use a spreadsheet because -- in spite of the GUI glitziness -- I find it a little bit cumbersome. I would feel it necessary to write a spreadsheet extractor that would turn the backlog from an Open Office Org file into ReStructuredText (RST). I prefer RST -- plain text markup -- over spreadsheets.

This is all protracted negotiation. Everything changes as a result of every conversation. That's the point of an Agile method. Quick sprint followed by negotiation over the direction of the next sprint.

Our backlog is a big RST document. We publish all our documentation using Sphinx and it's very, very simple to write backlog, use cases, architecture, design, etc., in RST markup.

Our sprints are simply sections of a big document tree. They're decorated with a few special-purpose interpreted text fields for the subjective things like estimated completion date, and status (in process, released).

Answer 2

What comes between the vision (solution to the problem) and the product backlog.

Nothing. From the Vision, you just create the Product Backlog (PB). Note that the Product Backlog Items (PBI) don't need to be all fine grained, only the most emergent items need to. So, don't hesitate to create coarse grained items at the start, you'll decompoose them into fine grained PBI "just in time" (this activity is known as backlog grooming).

With these 2 artifacts, you can start your project. As Ken Schwaber puts it: "The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is." (Schwaber 2004, p. 68)

From what I read, I think it is user stories but I am not sure.

To be honest, I'm not sure that I'm following you here. The PB is by definition a list of PBIs and creating the PB thus means feeding it with PBIs. Now, User Stories are just one possible formalism for the PBIs (Scrum doesn't force you to use User Stories, they are not appropriate for all projects) so, if you decide to use this formalism, creating the PB will mean creating User Stories.

Is there anything online that shows all the steps in a linear fashion from vision/concept to the end?

Below, one of the oldest illustration of the Scrum framework:

On the requirements gathering, just use Excel?

This would be my recommendation. If you need a sample, maybe have a look at Henrik Kniberg's Index Card Generator. More templates and/or samples at Scrum backlog templates and examples.