Decomposing functional requirements into the Product Backlog

Working with the mature teams willing to embrace Scrum and Agile concepts is a pure pleasure. Many people wrote many interesting books and articles regarding this topic.

If you are the part of such team, you can consider yourself lucky. It would be even better for you to skip reading this post, since I'm going to write here about some sad and disturbing issues. I'm going to focus here on the reality of freelance software engineers or consultants - working with the non-agile teams. 

Why keep you calling me a Product Owner?

Assume that your Product Owner doesn't get the idea of Scrum and Agile in general. She can just specify some general functional requirements and execute the realization of the them. You could keep on calling her a Product Owner - but probably she has never heard this term before.

You can assume that you cannot deploy Scrum into the project where client is unaware of the existence of the Agile methodology. However such decision will end up in sacrificing the quality of the product you deliver. If you still need to complete the project, then sneaking the Scrum into it would be a benefit for both you and your client.

Starting from the functional requirements

Non-agile Product Owners usually do not buy the concept of User Stories. They can merely express their needs using the plain-old Functional Requirements. High-level functional requirements to be specific.

If you ask non-agile client for User Stories you will probably get something similar to the following points:

• I want to restrict access to the page only to people from my department.
• I want  to edit and save my documents.
• I want to have a dictionary of my magic business data available to use when I'm working on my documents.
• I want to be able to import documents and dictionaries from system FOO managed by the another department.

Asking non-agile Product Owner for splitting the functional requirements above into the detailed User Stories will be considered by her as a waste of time. 

Decomposing functional requirements into the Product Backlog

It's your affair now (as a Scrum Master) to decompose these snippy functional requirements into the Product Backlog.

The technique that works best for me is to create a Google Document where I put the requirements from the client and convert them into the Product Backlog available for our team. The initial Product Backlog from our example requirements may look like:

1. User authorization

2. User management

3. Documents management

  3.1. Documents CRUD operations

  3.2. Import documents from system FOO

4. Dictionaries management

  4.1. Dictionaries CRUD operations

  4.2. Import dictionaries from system FOO

As you can see I use to manage Product Backlog entries as the hierarchy of ordered listings. I could easily identify story (like 3.2. Import documents from system FOO) or group of stories (like 4. Dictionaries Management) using the numeric identifiers. It is quite easy to manage nested lists in Google Document using tab indentation.

I manage Product Backlog in Google Document because it's easier to cooperate with agile-unaware people using the plain document than some kind of specialized tool. It is also easy to share the backlog and collaborate on it, track the history of the document changes and revert it to the previous version if needed.

Getting more details from the Product Owner

Non-agile Product Owner is a very special kind of one. You need to contact her in order to get some glory details of the Product Backlog (as opposed to working with the true Scrum Product Owner who willingly collaborates with you in order to create comprehensive backlog).

Now take a look at our rough draft of Product Backlog below, take a phone and call your client. Ask her to elaborate some point of Product Backlog. You could start with elaborating a group of stories 1. User authorization. After applying details fetched from the Product Owner you could improve your backlog to form similar to:

1. User authorization

  1.1. User enters login and password pair, to get access to the application.

  1.2. User logs into the application using her Facebook account, to get access to the application.

2. User management

3. Documents management

  3.1. Documents CRUD operations

  3.2. Import documents from system FOO

4. Dictionaries management

  4.1. Dictionaries CRUD operations

  4.2. Import dictionaries from system FOO

Now we got two complete User Stories 1.1. and 1.2. grouped under the 1. User authorization story group. Then you continue to nag your client with the next phones/e-mails/meetings as long as you iteratively complete the Product Backlog.

When this approach can be useful

Agile-unaware people tends to express their needs in the terms of Functional Requirements instead of regular User Stories. They usually do not want to sacrifice an extra time to rephrase their requirements into the Stories form.

I find this strategy of maintaining Product Backlog extremely useful when working with people who do not know (and do not want to know) Scrum (and Agile approach in general). I prefer to work with plain Google Document under such circumstances (instead of using Jira, Mingle or Pivotal Tracker) because it's easier to convince non-agile people to work with a plain documents instead of the dedicated tool they need to learn. Some Scrum-unaware clients feel more comfortable sticking to the Functional Requirements and plain old Word-like documents - this is my way to get around their habits.