How to build a product backlog?
In the beginning of projects, there is often uncertainty how to start with actual implementation of software product, especially when using agile framework.
In case of bigger projects for software development, with complex processes, there are usually many stakeholders involved. It could be that they have some basic education about agile framework, but often they do not have any practical experience in building the sofware product. In such cases, questions like following usually start popping up: „How do you start creating user stories?“, „What do you include in which story?“, „How do you build backlog of stories?“. In this article, I would like to share some ideas and try to give answers to those questions.
What is our goal?
When you start building a new product, it is important to be aware of the desired goal. The team will most likely get assignment to build a new solution or enhance some solution component. But the motivation for new or changed solution is usually some business opportunity, either to increase revenues or market share or to reduce costs through optimization of processes. Achieving of these business goals should happen through usage of new solution features. In case of increase of revenues, this means that some external end user will be so thrilled with your product that s/he will want to use it and pay for it. In case of process optimization, there will most probably be some internal user whose work might be much easier and faster due to new features, which will more or less indirectly again have impact on some paying customer. In either way, your goal will be to make your users/customers happy, because your product will be so cool and solve their problems and make their life easier. In order to achieve this, you should invest some tome into getting to know your customer and what s/he really wants and needs.
Road to delivering a product
In the next diagram you can see phases which you need to go through, in order to build a product. These phases are often overlapping and they are flexible, but in general, each of them needs to be done, in one way or another.
Learn about your customer’s problems and needs
In order to be able to make your customers happy, you should get to know them better. You should go through sequence of steps, that the customer is also going through. By putting your self into customer’s shoes, you will be able to identify and understand their current problems and needs. In this way, you make actual customer behaviour more tangible and you can use this as focus point throughout the process, when working on solutions.
When a team starts working on a new product, there is often a temptation to skip analysis of current processes and jump straight into defining the new solution. One should resist such temptations, because if you skip an analysis of current processes you will miss the opportunity to discover actual pain points, which are the key to give the purpose to your product.
The sources of information for such excercise might be your own knowledge, the know-how which is distributed among many stakeholders, but above all direct communication with your existing and potential customers.
For example, the desired business goal of some bank might be to develop more long-term relationships with the clients, through contracting more retail lending products. Current offer comprises service in branches and simple submitting of application through internet banking, and the rest of the process is then offline. As a result, the team’s product vision is to provide fast and personalized lending process for users, based on automated decision making. When analyzing main pain points and needs of customers, one can notice following complaints: procedure is slow and complex (how can we make it fast and simple), offers are standardized (how can we make tailored recommendation for each client), clients need to come often to branches (what can we offer online), clients need to wait to get monthly statement or go to branch to find out about current status of their application/loan (how can we provide real-time status insight).
Decide on options
Based on available business know-how and knowledge of technical possibilities, the product team should come up with a set of possible options for how those issues might be solved. The identified options should then be screened and compared, based on defined set of criteria and checking of prioritized assumptions. The goal is to reduce risks and examine value for users, technical feasibility, financial risks, etc. The points that I mention here are just the tip of the iceberg, but underneath is one separate important topic of managing assumptions and idea testing.
The result should be one solution option which forms the basis for next steps and building of actual backlog. This part of process can be done in different ways and it mostly depends on decision making procedures in each company. If these steps are done in a beginning of bigger project, respective decisions might be more high level and referring to definition of IT architecture, budget and resources allocation. In the same project however, these steps for options identification and selection will be repeated when defining further details for different solution components i.e. features.
Identify product backlog items
In order to come up with items for your product backlog, you will need to go deeper into details of how the future product might look like. In agile environment, it is especially useful to use different visual models. Such techniques enable seing the big picture, but they also show how individual elements fit to this big picture and what are the relationships between elements.
One of such techniques is Scope or Context Analysis. Based on previous example, this might look something like this.
It shows visually the solution, users, data sets and their interaction. When your team will be discussing about some details, it is very practical to use such an overview so that you can see where does the respective item fit in the big picture. You can also get aware if some customer group or their interactions have been overlooked and add them to the scope. The identified interactions are the candidates for backlog. At this level they will most probably correspond to „big stories“, the so called epics.
Another visual model, which can be very helpful to fill in your backlog, is Process flow diagram.
Main elements of this diagram are boxes (representing acitivities or process steps), diamonds (decision points), and arrows (showing the sequence of process steps). In case if you are dealing with a complex process, you might want to show activities of different user roles in different lines. For some of the boxes, there might be a need to decompose them further into more details. It can even happen that you will need to make more different process flows. There is always a question, how much information is enough, in order to start with implementation and how to organize the growing amount of information in a smart way, in order to avoid that the team gets overwhelmed. This is always a matter of balance and it depends on individual case, its complexity, possibility for hidden risks and dependencies. Showing the process in visual way makes great structure and it is easier to understand what is happening when, and to think about and discuss with your team other details relevant for implementation, like which data sets is the user dealing with during the process, which activities are triggering the status changes, which systems will cover which steps etc. Diagram can be more complex, showing all alternative paths, or simpler, showing only the happy path and providing details as addition to diagram (e.g. in form of some business rules).
There are also other techniques, which can be helpful to understand and discuss specifics within the team, like Data flow diagram, State diagram, Wireframes etc. All these visual models are the source of stories for your backlog. Their first versions might show higher level scope, and then, depending on your priorities, you will split each of them into more details, up to the level which is appropriate for a user story to be tackled in one sprint iteration.
Coming back to Process flow diagram, this is an especially useful artifact, as it makes basis for another visualisation tool called Story map. Story map basically lists all your backlog items, but in a way that allows you to place each epic/story into context, so that you can understand better how it fits to the big picture. Top horizontal row presents activities from perspective of user. Each story will be placed under respective activity, where it belongs in the process flow. When looked vertically, the items placed closer to the top row, will be of higher priority and with more details defined.
How to make a good backlog
In order to make a good product, we need a good backlog. In order to make a good backlog, some check points should be taken into consideration throughout the whole process.
Let’s go through the points drawn in the cycle in next picture.
The product vision is deduced from and aligned with some business goal. This mostly means, increasing revenues, increasing market share or optimizing processes in order to reduce costs. Therefore, in order to keep the company business viable, it is important that our product supports the product vision.
The customer will use our product only if s/he finds it useful for their needs. They will use the product, only if it provides the expected value and smooth usability.
Even if we identified the correct problems, if our focus during definition of solution is transferred to the solution itself, while forgetting about the problem that we are solving, it is very likely that we will miss the target.
If we form our backlog based just on one or two team brainstorming sessions, we will for sure end up with lack of structure, redundancies and undiscovered requirements, which will lead to many unclear and unnecessary discussions, scope creep and waste, further along in the process. Visual models can be very supportive for gathering of one own’s thoughts as well as for discussing with your team.
If we don’t define clear priorities, based on sound arguments from user point of view, our releases might not be well accepted and the team motivation might decrease.
When splitting epics into stories, we should assess which decomposition criteria is optimal for specific cases (e.g. happy path/alternative paths, split per different user roles, process steps, business rules etc.).
If we define too much details in advance, we might get overwhelmed, create confusion and frustration due to being stuck and lost in details, without any tangible feature.
We should refine our backlog regulary and have appropriate number of stories ready for next iteration.
If we release and don’t track feature usage and satisfaction of our customers, then we will miss the opportunity to correct our wrong decisions.
Backlog — building blocks of product vision
When looking at cycle presented above, one can notice that the backlog has a critical position in the process. Especially in the agile world, with its increased modularity, backlog is the main communication tool that holds together discovery and implementation phase and keeps the team on the common road. Backlog reflects the business needs and it feeds implementation. If backlog has wrong components, then the product will turn out wrong as well. If backlog structure and granularity are not optimal, it will cause confusion and frustration. If every backlog item was prepared with user needs in sight, then backlog as a whole will be a collection of building blocks, ready to turn the product vision into a reality.
