What is not true for the entries in the scrum backlog

The most simplified definition of Scrum Product Backlog is: ‘it is a list of all jobs that need to be done within the product’.

One of the most important skills that a modern leader can possess is the ability to transform his entire organisation into an Agile and flexible company, that’s why talking about the Scrum Product Backlog is very important!

Remember the ability to transform his entire organisation into an Agile and flexible company is just a small skill set that you must possess in order to ADAPT your company to the digital era! If you are an executive leader looking to ADAPT your company to the digital era, check more about our approach by clicking the link: ADAPT Methodology™.

While training some of my clients during the last few weeks, I have been continuously asked about scrum product backlog. To answer your ongoing questions, I have decided to research this topic more thoroughly and write this blog post.

The most simplified definition of Scrum Product Backlog is: ‘it is a list of all jobs that need to be done within the project’. They replace the traditional requirements of specification artefacts. Backlogs are designed in the form of user stories and can be technical in nature or user-centred.

Scrum Product Owner owns the Scrum Product Backlog. The Scrum Master, Scrum Team and other Stakeholders are all contributors. They have a broad and complete To-Do list to complete the backlog.

A typical Scrum backlog comprises the following items:

1. Features
2. Bugs
3. Technical work
4. Knowledge acquisition

The Scrum Product Owner uses a Scrum Product Backlog during the Sprint Planning Meeting to describe the top entries to the team. The Scrum team then determines which items they can be completed during the upcoming sprint.

Each Scrum Product Backlog has certain properties that differentiate it from a simple to-do list:

• an entry in the Scrum Product Backlog that always adds value for the customer
• entries in the Scrum Product Backlog are prioritized and ordered accordingly
• the entry’s level of detail depends on its position in the log – all entries are estimated
• it is a living document
• there are no action-items or low-level tasks

User stories are the primary way for Scrum teams to express features on the agile product backlog. The stories are short, simple descriptions of the desired function told from the perspective of the user. For example, as a shopper, I can review the items in my shopping cart to see what I’ve already selected before going to the check out.

Bugs and new features describe something different that a user wants. Because there is no real difference between the two, bugs are also part of the Scrum product backlog.

Technical work and knowledge acquisition activities also belong on the agile backlog. An example of technical work would be an instruction like: “Upgrade all developers’ workstations to Windows 7″.

An example of knowledge acquisition could be a backlog item about researching various JavaScript libraries, then selecting a library.

Working with the Backlog

A backlog needs regular attention and care; it needs to be managed carefully. At the beginning, the Scrum Team and Scrum Product Owner start the project by brainstorming and writing down everything they think of. The items that the owner and team come up with should be more than enough for a first sprint.

Scrum Product Backlogs are an ongoing process that comprise of the following steps:

• Add and describe new items to they the list as they are discovered
• Change or remove existing items as appropriate.
• Move high-priority entries items to the top of the log in preparation for the next sprint planning meeting
• Re-estimate the entries

While this is a collaborative process the Scrum Product Owner is responsible for making sure that the Scrum Product Backlog is in good, working condition. When using the Scrum Framework, about 10% of the Scrum Team’s total time should be reserved for maintaining the Scrum Product Backlog.

The collaborative maintenance of the Scrum Product Backlog helps to clarify the requirements and create a buy-in from the Scrum Team.

Common Pitfalls – Taken from Scrum Alliance 

• The backlog is often confused with a requirements document.
• There is no mandated format to represent the backlog: it can be an Excel document, a text file, database, a collection of index cards, or most commonly, Post-It notes.
• Creating a physical form backlog increases the risk of creating multiple and conflicting versions; this is a dire mistake because the backlog is a single, trusted source of the work to be done.
• Backlog items are atomic as opposed to narrative documents, meaning a single sentence could contain several distinct requirements, or conversely describe one requirement over several detailed paragraphs. The physical form encourages this “atomicity”.
• The backlog should not describe every item at the same level of detail, or “granularity”. Features and tasks that are planned for the near future should be broken down into fine-grained items and accompanied with other details like acceptance tests, UI sketches, etc. Items planned for the more distant future can be described at a more macroscopic level.

10 Tips for Product Backlogs – Taken From Roman Pichler

Working with the product backlog can be challenging; many Scrum Product Owners wrestle with lengthy and detailed backlogs. The following tips can help you work with your product backlog effectively:

Tip #1: Complement your Product Backlog with a Product Roadmap

Use a roadmap to sketch the overall journey you want to take for your product. State upcoming major release with their goals or benefits, then design your product backlog from the roadmap.  Use the goals to discover the right backlog items to ensure that you are in alignment with the product strategy. This helps you decide which items should be added to the product backlog and which ones should not.

Tip #2: Focus your Backlog on the Next Major Release

Use the product backlog as a tactical tool that states which product details–including epics and user stories– should be implemented for the next major release. This helps create a concise backlog that is easy to update and change.

Tip #3: Start with a Short and Sketchy Product Backlog 

When you create a new product or feature, keep the lower-priority items coarse-grained. Use customer and user feedback to decide which features to implement to evolve and refine the backlog items.

Tip #4. Collaborate with the Development Team

Involve the team members in the product backlog work. You will benefit from their knowledge and creativity while discovering technical risks and dependencies. It also increases the understanding and buy-in of the team members, resulting in better, more clear requirements.

Tip #5: Say No

Decline ideas and requirements that do not help you meet the release goals or bring you closer to the product vision. This ensures that your product will have a clear value-proposition while preventing it from getting bloated.

Tip #6: Look beyond User Stories

While user stories and functional requirements are important, they are usually not enough. You must also consider the user interactions, the nonfunctional qualities of your product, and the user interface when creating your backlog.

Tip #7: Prioritize your Backlog

Use uncertainty and risk to decide how soon an item should be implemented. Addressing uncertain items early lets you test your ideas. You can learn from the failures as you continue with your backlog.

Tip #8: Proactively Manage your Product Backlog

Regularly groom and refine the items with the development team. Analyze the feedback and data collected from exposing the latest product increment to the users, then apply the new insights into the backlog. Remove or update existing older items while adding new ones. This maximizes your chances of building a product that users really want. It also keeps the product backlog up to date and concise.

Tip #9: Get the Backlog Ready 

Break larger items into smaller ones by leveraging the insights gained from exposing product increments to the users. Ensure high-priority items are clear, feasible, and testable so they are ready for the sprint planning.

Tip #10: Make your Product Backlog Visible and Easily Accessible

Try a putting a paper-based backlog on the wall. This type of backlog has several benefits:

• It is clearly visible and creates transparency (when on the team room wall and people are collocated).
• You can see when your backlog is becoming too big because you run out of wall space.

Did you like this article?

We specialised in helping old companies reinvent themselves to become fast, flexible, modern and innovative businesses just like a startup! If you are interested in the 3rd pillar of the ADAPT Methodology – The Agility part you can check our Agile Consulting and Agile Training services. If you are interested in developing your leadership skills you can take a look into our Digital Leadership Accelerator.

Will You Succeed Or Fail As A Leader In Designing Your Digital Product Company?

If you want to know more about your company's digital product development maturity just take this scorecard. It will help you to identify all the different areas that you can improve and build a truly Digital Product Company.

TAKE THE SCORECARD

Which is not part of Scrum product backlog?

Which is not true about product backlog?

What does Scrum backlog contain?

What is true about sprint backlog?