Some time ago a colleague of mine, Monica Hervén, asked me for some advice. I was a bit surprised, because she’s a lot more experienced than I am and she’s someone who I have a lot to learn from. The issue she wanted to discuss was how to identify the requirements in a scrum project she’s involved in.
In the first post in this series I described how the requirements phase is generally treated in descriptions of scrum.
A scrum project starts with an almighty, all knowing product owner that has the entire list requirements prepared in a prioritized product backlog.
The problem Monica faced was that there was no clearly defined, prioritized product backlog produced by the appointed product owner. I don’t think that I had very much new to tell Monica that she didn’t already know, but we could share some experience of the challenges of getting a good product backlog produced.
The product backlog is the initiator for all work done in a scrum project. It’s the responsibility of the product owner to produce it. That makes the product owner role extremely demanding. It is impossible for a product owner to just conjure up a product backlog. Forming the backlog requires hard, structured work to ensure that all relevant user stories are identified.
Identifying User Stories
The first and most important step in producing the product backlog is to identify the user stories. In any project of non-trivial size there are tens or hundreds of user stories. It’s impossible to keep all the different user stories in mind at the same time. To ensure that all relevant stories are found, some kind of structure is needed. That structure is mapping of the business processes.
Business Process Mapping
A fictive business process map for a mail order company might have three main processes, which each have two major steps. For each step in each process, identify the actors and interactions. For the receive order step there would be two different user stories by two different actors.
- As a customer, when looking at a product on the web page, I want to place an order for it directly on the web.
- As a sales agent, I want to place an order that I receive over the phone from a customer.
The business process map helps with the overview required to find all user stories. Once found, the stories can be elaborated.
As a developer I like having a process overview as well. That helps putting what I do in a context. I strongly believe that knowing the context of the system makes it a lot easier for the developers to make a good implementation of the requirements.
Forming the Backlog
A first draft of the product backlog can be produced by creating a product backlog item from each of the user stories. It would be naive to just bring that backlog to a sprint planning meeting and think that it is well defined enough to be able to work with. Some quality control and second opinion is needed.
The quality control should be done by the project’s system architect. The architect can find what items that are best solved together and join into one item. Large items are split into manageable pieces. Dependencies between items, where one requires functionality of another one are found and documented. An initial estimate of the complexity of each item should also be done.
After the architecture review there are probably a number of questions that need to be answered before the items are ready for development. Those question need to be handled. The final description of the user story should also be approved by any stakeholders particularly involved.
When the user story is finally approved by both the architect and the stake holders it is finally ready to be considered a candidate for inclusion in a sprint.
Non Functional Requirements
The user stories captured from the process overview just captures one part of the requirements. There are also requirements that do not fit into the user story format.
A common example is performance. For a webb application it could be a requirement that no page should take more than 100ms to render (unless explicitly allowed in the specific user story). That is not something that can be implemented separately. It affects everything done. If a pages takes too long, it is not done properly. Such a requirement can be included in the project’s definition of done list. Combine it with a tool like Mvc Mini Profiler so that all developers can see the rendering time easily.
There are also some border cases, that are neither true user stories, nor is enough to just keep in mind through the definition of done. One example is logging. An approach to logging is to create a backlog item for setting up the logging framework and rules of the project and write any helper functions. Then the actual logging can be included in the definition of done list, as it should be considered for all code written in the project.
In a project there are a lot of things to be delivered to support the code written. I think that it is perfectly valid to add any deliverable to the product packlog. User Manual? Technical Documentation? Operations Manual? Add them to the product backlog. The developers will have to be involved in producing them, so it makes sense to put them in the backlog.
Another thing that I often put in the sprint backlog is investigations of some sort. If it looks like we are going to implement the great weyzabalanga user story in sprint 5, we’re going to know how to do that. It requires some investigation of weyza frameworks, to have decision on what to use when sprint 5 starts. Then it’s perfectly valid to put the weyza framework investigation as an item in sprint 4 and include the framework decision in the sprint goals for sprint 4.
Looking yet another sprint earlier that probably means that one of the goals of sprint 3 would be to have a first draft version of all weyzabalanga user stories complete, to have something to relate to when evaluating the weyza frameworks.
I know that planning ahead two sprints isn’t really the scrumish way to do it, but it is a way that works in reality so I’ll keep doing it until I find a better way.
Adding Requirements to the Scrum Project Picture
In my previous post in this series I wrote about project governance and made a picture of the scrum project with project governance surrounding the scrum project. It’s time to add the requirements to the picture.
The requirements transforms the projects goals into the product backlog. The requirements should also take any feedback from the sprint demos into consideration. The project governance loop has been enlarged, to keep its role as surrounding all the the other activities of the project.
Don’t Forget Requirements
With scrum being so focused on productivity of the developers it is easy to forget the requirements phase. Just becuase we’ve (finally) found a great way to get developers productive doesn’t mean that we can ignore the requirements. Successfully forming the product backlog is one of the key success factors for any scrum project. Make sure that the project setup includes a process and resources for handling the requirements.