Postulates for Backlog Prioritization

Today, I am continuing my discussion of backlog management. A good backlog follows Roman Pitchler’s DEEP model. Sticking with three simple building blocks inside your backlog will streamline work, and placing all work that drives value in the backlog will make you more successful than half of the other product owners currently working. This week, I want to discuss something that many organizations struggle with – prioritization.  

As a software developer and agile professional, I spend plenty of time around entrepreneurs and business executives. Many of these individuals are insulated from the hard knocks of life by the success in their careers. Because business leaders are accustomed to getting everything they want every time, they need help when asked to set priorities. People unaccustomed to hearing no are notoriously tricky to work with. 

The cold reality in the global economy is limited time, people, and money to get things done. Bosses who create a climate of terror destroy their organizations. Therefore, priority setting is necessary sooner or later. Confronting this reality requires a few postulates for business people to understand. 

The first postulate of prioritization is if you do not set priorities for work, someone else will. When you give a software developer a list of things to do without priorities, they will work on the most straightforward task or the one that interests them personally. It means employees often spend their time on tasks that are optional to the business. It may not be a big problem at first, but it will create situations where a developer will build something, and it will be radically different from what the person paying the bills asked for. 

The following postulate is that when everything is a top priority, nothing is. In business, there are important things and things which are urgent. Rarely do the two overlap, but business leaders want to create a false sense of urgency to get work done. It is a recipe for failure because if items are all urgent and essential, they are just like they should have been prioritized. The easy or enjoyable tasks will go first, generating conflict between the employees and management who commissioned the work. 

Finally, we should prioritize work based on the needs of customers and stakeholders rather than the highest-paid people in the room. I have spoken at length about egoware and other types of waste in organizations. The top priority for any business is the customers who pay for the solutions and products the business manufactures. So, when confronting a situation where a customer conflicts with an Executive Vice President of Application development, you must side with the customer. Improved revenue and better profit margins have a way of silencing critics. 

So, for a backlog to be successful, follow these three postulates of prioritization. First, set priorities; otherwise, others will set them for you. Next, priorities need variation because if everything is a top priority, nothing is. Finally, prioritize based on customer needs instead of management desires. These postulates are the foundation of a successful backlog. A successful backlog is the beginning of a successful agile implementation. 

Until next time. 

A backlog must be DEEP

I am continuing my series of articles about the basics of healthy product ownership. The most fundamental thing in Agile is the product backlog. Borrowing from Dave Todaro and his book “The Epic Guide to Agile,” I said that the basic building blocks of a product backlog are user stories, bugs, and tasks. Today, I want to emphasize the structure of a backlog. 

Roman Pichler writes plenty of great books about Agile. My favorite is “Agile Project Management with Scrum.” Here, Pichler outlines his DEEP model of product backlog management. For a backlog to be robust, it must have the following necessary and sufficient conditions:

• It must be Detailed.
• It must be Estimated.
• It must be Emergent.
• It must be Prioritized.

I have blogged about each of these conditions in other blog posts. Today, I want to review them again and develop some structure you can use to ensure that your backlog is healthy and helping drive value. 

Many businesses actively view a product backlog as a grocery list to fill. It is a mindset geared toward failure. Even the most successful software projects began as small experiments that grew and adapted to market conditions. So, unfinished items are revised based on what the customers want. That is why we say a backlog is emergent and prioritized. A business must determine what is important and do those things first, and if the market determines those priorities need to shift, we must be flexible and intelligent enough to change them. Ego is the enemy of agility. 

One of the most universal features of project management is that once you start doing the work, there is no way to know how long it will take to complete the task. The reality is known as the cone of uncertainty. Estimates can be wildly off by a factor of eight from the low end to the high side of the budget and timeline. The only way to reduce the uncertainty is to do the work, which means that you are adding more detail and information to user stories. It also means that estimates may change as more information becomes available. The code of uncertainty will narrow, but it will take time and patience, which are in short supply in the global economy.

The properties of detail, estimation, emergence, and prioritization combine to make your backlog resemble a leaderboard at the golf event. A golfer rises and falls on the board based on the condition of the course. Halfway through a tournament, a cut takes half of the golfers out of contentions—the ones who make “the cut” then compete for the real money and recognition. Instead of golfers moving up and down a leaderboard, think of the user stories moving up and down the backlog based on the competitive information from your customer base. 

The road to healthy product ownership travels through a detailed, estimated, emergent, and prioritized backlog. A product backlog that meets those conditions will deliver value to the project and generate revenue for the firm, which keeps everyone working for another day. 

Until next time. 

Back to Basics the Building Blocks of a Backlog.

I want to return to basics for the next few weeks and discuss Agile fundamentals. Last week, I outlined my mission statement that the fundamental building block of an agile implementation is a product backlog. Today, I want to discuss the items you put in the backlog. 

I am currently reading Dave Todaro’s book, “The Epic Guide to Agile,” which I am enjoying. Todaro starts with the basics of Agile and Scrum. From this starting point, he covers the pragmatic impacts of applying agility to business. It is from here that he talks about product backlogs. In case you need a refresher, a product backlog is a list of work the team must do to deliver value to the organization. A backlog can cover numerous processes, from marketing to Human Resources, but my examples will focus on software development since I am a technology person. 

A product backlog should contain user stories, bugs, and tasks. A user story is a new functionality or a change in functionality that creates value for the firm. For instance, if you want to tie the corporate website to a Federated social media service, you create user stories for the development team to improve. Another example is when regulations change, you must change how to calculate sales tax in the shopping cart. User stories are uniquely suited to adding features and improving products. If you want to learn more about how to write user stories, you can follow this link, where I talk about how I teach others to write user stories. 

The next item you should add to a backlog is bugs. A bug comes from a funny story from the early days of computer science. The first computers were monstrous contraptions the size of entire buildings. These devices came before the invention of transistors and microchips, so they were composed of rooms of unreliable vacuum tubes that gave off unhealthy heat levels. According to National Geographic, a moth flew into one of these rooms and landed on a tube. The insect died instantly and shorted out the computer. Since then, anything physical or programatical that breaks a computer is called a bug. 

The product owner of a system needs to track bugs in a system. Thus, log a bug when something is not working as expected in the product backlog. For instance, if we return to our fictional shopping cart and sales tax. We must write up a bug if sales tax is incorrectly calculated. From there, the bug is prioritized like a user story and then worked on by the scrum team. 

We need to remind people not to get hung up on if they are working on bugs or user stories. As a developer and scrum master, I often argued about work. I always wanted to debate if something was a bug or a user story. A wise coach showed me that both product backlog items are working to drive value to the firm and that I should concentrate on the work instead of arguing about what kind of work I am doing. 

The final item in our backlog is called a task. It is an item that the team does which does not deliver direct value to the solution. Training, the configuration of environments, and product spikes all fall under the umbrella of tasks. At first, I disagreed with this approach because I consider spikes a separate entity. My attitude changed when I started working at organizations where twenty different product backlog types existed in instances of Jira with different workflows. Thus, spikes and work that do not add direct value to the product should be treated as tasks to avoid headaches in Jira and simplify managing backlogs. 

A product backlog lists User Stories, Bugs, and tasks. Together, they make up everything a team does to deliver value to the organization. Please avoid focusing on the specific details of each type and accept that all of them must be completed. Next time, I will discuss Roland Pitchler’s DEEP model of organizing a product backlog.

Until next time. 

From the Basics to Healthy Ownership

Agile professionals tell tales about our successes and failures regularly. It is how we learn about what works and what doesn’t in our profession. Agile people also enjoy a good tall tale about the foibles of working in the global economy. After some time, these tall tales become apocryphal stories that we share. I am guilty of this behavior, and I am sure other coaches do it. Today, I want to pull back from the mythology surrounding agile and focus on the basics. 

I am reading Dave Todaro’s book “The Epic Guide to Agile.” What I like about this book is that it concentrates on the basics of agile and scrum. Todaro builds out advanced concepts from the basic foundations grounded in years of experience working with software professionals and business people. It is refreshing to see this writing about agile. 

As a coach and scrum master, the most fundamental building block is the product backlog. It is the bedrock where most Agile efforts begin. It is also where we see the origin of many of the dysfunctions in a business. When reviewing the subject, a product backlog is a prioritized list of work, including user stories, bugs, tasks, and spikes. A product owner creates and prioritizes that list while a development team completes that list. In contrast, a development team completes that list, checking off individual stories.  

Backlogs work on the level of individual teams. When coordinating between multiple units, we create what the people in SAFe call a value stream. Value streams then roll up into portfolios of work. Thus, you can roll work up into larger blocks or break it into its most fundamental levels. We aim to have a clear view of what is being worked on and measure how much value is generated for the firm, not to create busy work at the organization.

To avoid getting lost, Agile professionals need to be able to measure progress and draw maps of where we have been to where we are going. It takes organization and a particular discipline, but if done correctly, you can communicate clearly with both business leaders paying the bills and development teams doing the work. The push-pull between the two groups is what I like to call “healthy ownership.” In a perfect world, leadership trusts the organization to get work done and can trust leadership to look after them. It should be a beneficial and mutually symbiotic relationship. 

Over the next few weeks, I will focus on how to help build healthy ownership in organizations, from setting up backlogs of work to ensuring that middle management does not strangle agility efforts for selfish reasons. I look forward to you joining the conversation. 

Until next time.

A Place for the Manager in the Agile Organization

I am always impressed by my fellow Agile advocates. Some are grumpy cynics who see failure around them and feel responsible for helping clean up the substantial debris cluttering global business over the last fifty years. Others are cheerful warriors attempting to show a better way by living example for others to follow. My approach lands somewhere in the squishy middle as I see behavior that violates my values. I understand intellectually that these violations are occurring because people created those systems to normalize those violations. 

As an agile professional, I have spent the last ten years fighting the uphill battle of changing business culture and performance. A common observation we in the Agile community have when we attempt to bring Agile to organizations is that teams quickly adapt to this new reality. Managers, in particular, are a constraint on how successful agile is in an organization. Today, I want to discuss the manager's role in an organization. 

My coach at CAPCO Financial, Michael Guerrero, ruefully observes that middle management is where agility dies. Executives know the importance of being more agile, and teams embrace the ethics of agile frameworks like Scrum and Kanban. Managers are often caught in the middle and do not know how to navigate an organization transitioning to agility. The challenge of finding a place for a manager is becoming a central question in the agile reformation, along with how to scale it to the entire organization. Diana William and Liz Rettig from Project Brilliant gave an excellent presentation at AgileIndy 2023. 

The Scrum Guide and Agile are very good at defining the roles of a scrum master, product owner, and team member. The Agile community is silent about where managers fit into this system. It does not help that we do a poor job selecting and training managers and that those who advance into those roles behave in ways detrimental to the organization. Instead of making middle managers scapegoats for the failure of agile, coaches and scrum masters need to recruit them as partners for success. 

Williams and Rettig suggest four roles for the manager in an agile environment.

Provide Strategic direction –

Managers need to provide clarity and direction to the teams. They explain the 'why' of the decisions made and let the agile teams figure out the 'how' and 'what' of work. In traditional managerial roles, they thrive on ambiguity in an agile environment and must provide clear guardrails for performance and conduct. 

Grow People – 

A manager in an agile environment must grow the people they serve with training and development so that their skills become more 'T' shaped and they can advance within the organization. Even a person content to remain in the same position can learn to be better at their job. Managers of this type are judged by how they grow the people under their care. 

Create an Environment for Success – 

Managers in an agile environment need to learn how to address constraints and impediments. These managers must create solutions to these blockers and create an environment where people want to work. It is more than coffee, pizza, and foosball tables. It includes reducing technical debt outside the team and getting collaborations from other parts of the business. 

Being an Agile Champion – 

Finally, a manager in an agile environment champions the process. They encourage retrospectives, support efforts to build psychological safety, and allow teams to design their work areas. They must be willing to exhibit the same continuous improvement they expect from the development team. Finally, they need to get out of the office and talk with the scrum masters, product owners, and stakeholders to ensure they have what it takes to succeed. 

These are the four roles of a manager in an agile environment, and they will look alien to people accustomed to sitting behind a desk and doing administrative work. It is a much more hands-on role. 

When we portray agile in organizations, we show it like a three-legged stool with the development team, scrum master, and product owner, each playing a supporting role. We intentionally exclude the manager. If we want Agile to succeed, we must change this mindset to include managers. Thus, a manager should envelop the team providing these four services to make each of its legs successful.  

The next five years will be critical for Agile's success, and it is up to us in the profession to ensure managers are not left behind.

Until next time.