My career is an adventure. Each week, I face new challenges as I attempt to help organizations deliver working solutions for the last ten years. I have experienced the Good, Bad, and Ugly of the technology business. I have never been a significant player, but in my small way, I have attempted to make life in the cubicles of your local office park a better place to work. Last month, I concentrated on creating a quality product backlog, and today, I want to summarize my thoughts on the subject.
A product backlog is nothing more than a fancy list of work to accomplish. It should focus on delivering value to customers. Finally, it should obey the principles of Roman Pitchler's DEEP model. If these simple requirements are satisfied, your project and organization will be more successful than many attempting an agile transformation.
The business exists to provide goods or services to customers. If done correctly, it is a mutually beneficial relationship where the customer gets what they want while the business makes a profit. It is up to the business to minimize waste and keep the customer happy. I am always amazed at how often this idea gets lost during a project.
Inefficiencies and dysfunction reveal themselves during projects, and many of those issues are not engineering issues but are instead the products of human frailty. Ego and insecurity stalk the cubicles of many business organizations. High-paid executives throw their authority around to justify their existence. People will claim credit for work they did not do. Finally, pressured for time and short-staffed, people are expected to create complicated software solutions. It is no wonder that burnout is so rampant in the industry.
I consider a healthy product backlog to be vital to success. Prioritization pr
events the highest-paid person in the room from overriding the organization's goals. By pointing out the importance of work to the organization and customers, questions of ego and authority fall away. If priorities are out of line with market demand, then the organization can pivot because the product owner and leadership team have an emergent backlog. We are empowered by estimation to make informed predictions about when work will be finished. Instead of an entire file cabinet of requirements that no one reads or refers to, the level of detail is sufficient to create working solutions.
A simple structure of Bugs, User Stories, and tasks obeying the same workflow reduces conflict within a team and the larger organization. I wasted ten hours of billable time getting a development team to accept a product backlog item as a defect instead of a change request for one client. Because they were not paid to fix defects, the team treated everything as a change request, wasting time and avoiding the need to mitigate their poor code quality. A more straightforward backlog structure and clear expectations would have saved everyone involved time and money.
The most crucial part of having a clear product backlog is that it is a public and transparent way to communicate how work moves through the organization. If someone wants to add work, they have to go through the product owner, and they can see the story move from creation to development to production. The organization sees how work flows through the system, and the organization can use the theory of constraints to help make necessary improvements to the system. Just like there are no secrets at a crap game, a good product backlog does not have any secrets.
Each week is a new adventure, but with a proper backlog, most surprises are not career-threatening.
Until next time.
No comments:
Post a Comment