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.
No comments:
Post a Comment