Agile methodology has become a leading one when it comes to software development. It has really allowed teams to step things up and create products that bring real value to its users. One of the reasons agile and SCRUM process is working out so well is product backlog. However, before we create it, here’s a few important things you should know about product backlog.
What is Product Backlog?
Product backlog is like a map when you’re on a road trip, your guide in an unknown city or a timetable for your first public transport ride in 3 years. Long story short, it’s important.
When you have software requirements specification for your project, there’s pretty much only one thing left – product backlog. It’s a document, that consists of a number of tasks needed to be done in order to develop the product. These tasks are prioritized based on their importance in the whole process. The ideal product backlog is prepared in a way that allows the team to develop core functions first.
When you’re working in sprints you should have at least 1-2 sprints fully prepared in a sprint backlog. Why? It helps creating a picture of what will the team work on in the near future. However, it’s best to have at least some knowledge on all sprints. The further ones don’t have to be specific but it’s good if they’re written down.
From Product Backlog to Sprint Backlog
Sprint planning is another aspect of software development that is fully based on product backlog. The team with SCRUM Master, Project Manager (if there is such) and Product Owner prepares a more detailed plan for the sprint. It’s not only a responsibility of a Product Owner since there’s a need for more technical details.
It contains informations like a description of a feature, what value it brings to the business, priority level and a time estimation. Developers start with the features of the highest priority and continue with the lower priority items.
Backlog refinement
An important thing worth to remember is the fact that product backlog is not that type of a document that stays in the same form for the whole project development, At least it shouldn’t be.
The more time the team spends on the project the more they know about it. That’s why it’s so important to use sprint retrospective meetings and sprint planning meeting for discussing the next tasks and scheduling backlog. Product backlog should be agile and refined with the project progressing.
Implementing changes in product backlog shouldn’t be perceived as something negative or that it was poorly created at first. The whole purpose is product backlog is to maximize the efficiency of the whole project. If it means making some changes along the way, that’s perfectly fine.
The Role Of Product Owner in Product Backlog
One of the most important roles when it comes to product backlog is Product Owner. He/She is the one responsible for creating, managing and refining backlog.
First, how does the Product Owner create the backlog? Based on specification documentation Product Owner needs to look at the requirements and create tasks that will allow the team to achieve the expected results. Because Product Owner doesn’t always have a technical knowledge, the team and project manager can also be helping with that. They’ll help with estimating how long something will take or suggest to divide a task into smaller ones.
After every sprint there’s a sprint review where the team meets to summarize the last sprint. Product Owner gives feedback and goes into details about the next sprint. There might be a need for backlog refinement to add some details, estimates or even change some priorities.
Tools for Sprint Planning
Creating, maintaining and managing product backlog might sound like a headache sometimes. Luckily, there’s plenty of tools that help keep everything on truck and very easy.
We’re just going to focus on one, probably the most popular one in software development – Jira.
Jira is one of the most common project management tools in software development. We personally use it in most of our projects. It can be easily customized to your needs and has a variety of integration options.
If you’re looking for more options, here’s a pretty interesting article where you can see top 10 best SCRUM Tools. It will definitely help you choose the best one for your project.
Common Mistakes in Managing Product Backlog
Managing product backlog is not something everyone will be good at since the very first project. As everything, it takes time to learn and get some practice. Whether you believe in 10 000 hours rule or not, there’s at least a little bit of truth in the saying:
It takes 10 000 hours of practice to make you an expert in anything.
You definitely don’t need 10 000 hours to be a good product owner or project manager but it definitely gets better with every hours.
That’s why even some of the best ones make some mistakes. Here are some common ones in managing product backlog:
-
Too many tasks to the point where they’re unmanageable
There needs to be a certain balance in product backlog. Many Product Owners try to be as prepared as it can be to the point where the whole development process is already divided into detailed tasks including the very last sprint. Unfortunately, it’s almost impossible and completely inefficient to manage around 600 tasks at the same time. Moreover, what about being agile? Imagine refining about 600 tasks after the first sprint. Focus on your current sprint and the one after that. The rest can stay very general. It will be a lot easier to systematically create new tasks to develop features instead of having to deal with everything at the same time.
-
Being too general or too detailed
Being responsible for product backlog can be very tricky. When we’re talking about specific features in the product backlog there needs to be enough informations but not too much. What does it mean? Development team needs to understand business logic behind the feature, understand the issue to propose the best solution and meet the requirements. However, the issue can’t be so detailed to the point where it’s a solution or a specific type of implementation. Try telling the team WHAT there needs to be done but avoid telling them HOW to do it.
-
Ubiquitous language
Ubiquitous language is basically a dictionary of terminology used by a company and being implemented to a project at the same time. It means that every company has specific names to certain products or processes. The goal for development team is to implement this terminology to the everyday use, to the source code and in meetings.
-
Lack of prioritization
One of the most important aspects of lean development is focusing of creating a real value, core functionality within the first sprints of the process. It can allow the product to be launched a lot faster and the rest can be added as an update later on. When there’s no priority list these core functionalities can be pushed back. It not only causes the value to be created much later but also can cause some other issues. All other functionalities should complement the core functionality. When there’s lack of it, the rest might not be developed well.
-
Little to no refinement
It’s important to look at the project during every sprint as something that can be always better. What it means is that agile methodology gives us the power to look for different solutions to make the project as good as it can be. Backlog refinement is an important part of it. Moreover, make sure to always implement this change in all future features etc.
-
Lack of teamwork
Last but not least, the product is developed by the whole team and every person in that team can add value to the product itself. Developers can propose some great solutions that the project will only benefit from.
Summary
Creating, maintaining and refining product backlog can be challenging for someone without experience. However, it’s definitely something that can be done with enough effort. Don’t hesitate to ask for help project manager or development team.
Focus on business logic, problems this product should be able to fix and what it needs to work efficiently.
