Get certified - Transform your world of work today

Close

Recognizing the Five Symptoms of a Poor Backlog

An a two-part solution

2 January 2018

Pratik Kothari
John Deere India Pvt. Ltd.

Understanding the backlog

The backlog is a single source of prioritized development objectives, tracked either by sticky notes or a backlog tool. The backlog provides a clear path for the business and IT when considering what’s next for development.

Agile Teams continuously run short iterations to deliver working software, and the backlog is the starting point that indicates what to sign up next. It is important that this backlog have clear, prioritized value objectives. If the backlog fails to give direction for feature or product development, chances are that the Agile Team will not deliver what the customer demands. It is the fuel that runs the sprints. It is the single source from which business can get an idea of what remains for future feature work, contributing to better decision making.

Assuming that your team does not have a backlog, how will they plan their sprint and how will the business know what will be delivered next?

I have identified five symptoms of a poorly defined backlog, which indicate that the team is not working effectively and needs improvement.
 

Five symptoms of a poor backlog

There are various early indicators that your product owner is struggling to provide clear direction to the team. If the direction is not clear, the results will not be promising, and ultimately the business will struggle, impacting the organization’s profitability. In my opinion, it is important to watch for symptoms as early as possible so that proper course correction can be done to improve the entire process.

Symptom 1: Poor planning

When a Scrum Team struggles to define a solid plan during the sprint planning session, and the product owner is not able to provide clear direction, this is the first indication that the team has a serious problem.

In this case, the result of the planning meeting will be either no planning or objectives that do not have a clear value defined. I call this impulsive sprint planning. The sprint was planned without any business inputs, and it was held only for the sake of holding it. It is not a winning situation for the organization, because it will not get a good return on investment. It will not only affect spending but also timing and opportunity to beat the competition.

If the team is in the early stages of its Agile movement, it is acceptable to have this type of situation for a couple of sprints. However, it is important to recognize this symptom and have an open dialog with the product owner to resolve the problem.

Symptom 2: Not enough detail

When your Agile Team is conducting its sprint planning, do they elicit the required details of the stories? If not, your Scrum Team is running the risk that they will not be able to deliver what they commit and will ruin the team’s credibility.

Ideally, during backlog grooming, someone from the IT team is involved in capturing the right level of details needed for the development team to be effective during its sprint planning. It’s common to not have IT representation during backlog grooming. If you feel that this is the typical situation for your team, consider having your tech lead or architect work with the product owner prior to sprint planning.

Symptom 3: More than 20% churn in objectives

If you are running two-week sprints and your business objectives are constantly shuffling, this is an indication that your backlog is not solid. Your product owner has to work hard to lock down the objectives. Some degree of churn is expected, but if it is frequent and more than 20%, the product owner deserves feedback.

Showing agility to the business is important, but if this churn is frequent, curtail it. It’s OK to have churn to support the business, but if it is the result of poor backlog planning, course correction is required. All types of changes have a cost associated with them. The product owner should be able to recognize this pain and work toward solidifying the backlog grooming process.

Symptom 4: The customer did not like the feature

If your customers do not like a recently released feature and provide feedback, this is one sign that the customer’s voice was not considered while hardening the backlog, or that customers were never consulted during that process. It is important to listen to the customer during the backlog grooming process. It will not only help the team deliver the right product but also save a lot of money in developing non–value-added objectives.

In the end, a feature is developed for the customer, and they should be at the center of the requirements gathering and consulted early and not late in the process. If you are frequently hearing feedback from the customer about a feature not meeting their expectations, why not involve them in the process? This can take the form of inviting some of the customers for the demo so that course correction can be made based on their feedback. Customers will also feel engaged during development.

Symptom 5: Running out of funds

Is your objective always running out of funds? It’s not uncommon to see software development objectives run out of funds because of ever-evolving business expectations. It is the product owner’s job to find out what is a must requirement and what is a nice-to-have requirement.

A team that is investing a lot of its time in nice-to-have requirements and later finds that it is now running out of money to deliver the must requirements is seeing a bad indicator. Instead, the team must deliver the must requirements first and, if time and budget permit, focus on nice-to-have requirements. The next time you find that your team is running out of money to deliver must requirements, consider that they are not getting the proper direction. Coach the product owner on prioritization by entering into a simple dialog or setting expectations for the individual.
 

Effects of a poor backlog

The product backlog plays a major role in product development. If it is not properly defined, the development team struggles with delivering objectives that matter to the business and that directly impact the organization’s profitability. It is a driver for successful product development, and if this direction is missing, reaching the organization’s goal is impossible.

The product backlog also plays a critical role in engaging the Scrum Team. If the product owner is able to effectively articulate the business challenges to the Scrum Team, then he or she can point the Scrum Team in a positive direction. However, if the business objectives are uncertain or there is no rationale behind some of them, the Scrum Team is unmotivated because it is unable to understand what value they are providing and how they are going to impact customers.

The repercussions of a poor backlog are high, and an organization cannot afford this situation for too long. As soon as any symptoms occur, it must correct the process. The product backlog should be the center of development, and we have to always keep it current and meaningful.
 

Applying a two-part solution

If you are in your early days of Agile adoption and have one or more symptoms of a poor backlog, try a two-part approach that could push the team in the right direction; they will think about a potential solution. The goal is to have an entire team — the business and IT team — work together and show agility to beat the competition and provide the best solution to customers.

Part 1: Set expectations

The product owner is the voice of the customer and is closely tied to the delivery team. Therefore, set the right expectation with the product owner.

Ask the product owner to apply a priority order to the backlog, with a clear Definition of Ready and defined stories and acceptance criteria. Developers and business stakeholders should be able to easily understand the criteria, and the product owner should provide the proper insights whenever required. The product owner should also define which story is a must for the feature and which story to consider as a nice-to-have. When these stories have been identified, it’s easy for the development team to start working on the backlog.

Part 2: Schedule regular backlog grooming sessions

It’s typical for a new Agile Team to have a product owner who struggles to define the priority order of a backlog. Everyone is confused about where to start and how to start. To solve this problem, run a common backlog grooming meeting in which the product owner, product manager, and someone from the technical team meet regularly (weekly is recommended). This team should discuss current business opportunities and potential IT solutions, and rearrange the backlog according to the current business priority. This meeting should provide a solid foundation for the backlog grooming and thus enable the product owner to provide clear direction to the Scrum Team.

The meeting should not only focus on the current and next sprint but also continuously work toward the future direction of the product. The product backlog sheds light on the path of product development.
 

Conclusion

It is impossible to remain competitive in the market with a poor backlog. Although it is common to have struggled with the backlog grooming, for the organization to remain profitable and meet the original intention of being Agile, it’s important to recognize the symptoms of a poor backlog, embrace the ensuing challenges, and move in the right direction.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.5 (4 ratings)

Comments

Agarwal Kanchan, CSPO, 1/2/2018 1:34:11 AM
A good read.You pointed all the right mix for an effective backlog.
I am currently performing the role of a product owner and having a regular grooming session does help a lot in re prioritizing all the stories.
There is one factor about the customer liking which is talked about here,in my view point it is very qualitative.As suggested a regular demo and having them tightly coupled will ensure a higher level of satisfaction.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe