When it comes to agile we all have seen how Scrum has the most commonly used framework because of its lightweight and easy-to-understand abilities. Most companies have gained agility and are ready for competition in the market. Many people see various benefits of scrum implementation including customer satisfaction, quality product development, employee satisfaction, shorter time to market etcetera along with the biggest benefit of using scrum for complex problem-solving. But many of them I come across, even me at the start considered that mere implementing scrum is enough to obtain such benefits. But with years of effort and adapting it, I come to understand that it is not as easy as said. To obtain such success employees need to be trained and educated on using scrum techniques and tools. Most of the time when desired success is not obtained it is because the scrum team function in a scrum anti-pattern which disrupts the workflow of a Scrum. I have seen how anti-pattern has reduced the product and business values if not acted on time.
When in business always know to be, “Calm, but alert. Relaxed, but ready. Smooth, but sharp. Humble, but confident.”
To be always alert and ready for challenges we must know where we as a team are going wrong. And the most common wrong direction we take is Scrum anti-pattern that disrupts the team’s workflow. So let’s start to get ready and know about the most common scrum anti-patterns.
I am a Scrum Master and have seen many team members who at the beginning learn Scrum practices and start using them without understanding the underlying principles of them. Similarly, Scrum anti-patterns are the expression for software that is attractive and easy to apply solutions but leads far away from problem-solving causing to create much bigger issues. This anti-pattern can be divided into main five categories and sub-categories. In this article, we will be discussing only the general anti-pattern of a Product Backlog.
General Anti-pattern
Oversize
This is the most common anti-pattern. The Product Backlog consists of more items than the team can deliver within three to six sprints. Team spends time in refining items that will not be delivered in next 3-6 months rather than focusing in next couple of Sprints.
Prioritization
In general Product Owners accountable for having a refined Product Backlog and prioritizing it. I have seen Product Owners prioritize the backlog but are not able to keep up the priority and get too much influenced by external stakeholders and do not consider team members view and technical stories that are required to get the functionality delivered. Product Owners prioritize multiple stories as high and do not order the backlog.
Stale Items
The Product Backlog consists of items that are there for six, eight, or more weeks which may by now are depreciated from their value in the time being.
Estimation for Every Item
Excess detail and estimation of the items will only create a waste of time as many times it is too much upfront work and risks categorization. It is advisable to refine the Product Backlog items in an ongoing process.
Component-Based Entities
Product Backlogs are split horizontally by component rather than vertically by an end-to-end user characteristic.
I.N.V.E.S.T
Teams must use Bill Wake’s I.N..V.E.S.T principles and create independent, small work and valuable items which will reduce the risk of execution failure during a Sprint.
Detailed Entries
Some items consist of a detailed and too much list of acceptance criteria, instead of going with three to five acceptance criteria which are enough. More than this means a Product Backlog is too large.
Missing out on Acceptance Criteria
No acceptance criteria should be missed as per the requirement to have the Definition Done. It’s good to be ready with all required acceptance criteria at the beginning of refinement.
Not anything more than a Title
Product Backlog consists of items that only have titles. It impairs the team’s capability of creating valuable product increments.
No Experiments
These issues are mainly related to having more focus on the discussion of future tasks and spending too much time on them rather than exploring them through Spike as a part of a continuous process of product backlog refinement. That means the Product Backlog has very few or almost no spike or limited-time research tasks.
Totally Upfront
It is so wrong to create a complete Product Backlog at the very start of the project. As Scrum mainly deals with complex issues we cannot tell when the new issue will occur and hence we cannot predict the complete project Product Backlog all at once. It is always wise not to have a complete upfront Product Backlog for the project.
These are the general Product Backlog anti-patterns that are so common in many teams and must be avoided. With the other anti-pattern categories I will shortly come up with an article on our blog so stay tuned.
About Advance Agility
We, at Advance Agility, are the new-age Agile Coaching, Consulting and IT services company. We enable end-to-end Digital Transformation. Agile execution is integral to our being. We are doing SAFe implementation with small, medium and large organization across the globe. Our vision is to be the leading Agile execution player globally. To keep adding value at every process stage. We are on a mission to empower our clients, move from concept to cash in the shortest sustainable lead time by adopting human centric approach to business agility. Embracing the change is in our DNA. Things that keep us apart are Quicker and Seamless execution with End-to-end gamut of services. Our Global presence and Stellar Track Record give us an edge over our competitor.
Connect with us at advanceagility.com to learn about SAFe and SAFe Implementation. Write to us at contact@advanceagilty.com for any agile training or consulting needs. We are always looking for competent agile trainers as well. So if you are a good trainer or want to become one, do get in touch with us to that we can learn, grow and achieve together.
Connect with us for boosting your work principles and practices as Scrum Masters or Agile leaders
Comments