Scrum and Backlog Prioritization
I think of Scrum Backlog prioritization as if it is a restaurant experience. The backlog itself is a menu arranged to fit the customer’s needs. It keeps in mind any dependencies (the chef can’t cook the eggs if the chicken hasn’t laid them yet), and is prioritized with their most important needs at the top.
The business chooses from the the menu based upon what they crave the most while keeping in mind their budget and time constraints. They put their top choices in the order of what they desire most, followed by things that would be nice to have if they have the appetite and time to enjoy them.
In this analogy, the Product Owner takes on the role of the waiter. The PO interacts with the customers and understands their desires. The waiter (PO) is well-versed in the food items and in some cases can help the business decide what to order. The PO then relays the orders to the chefs (or developers in this scenario) and they begin to cook the meal.
It would be considered bad taste for the customer to go into the kitchen and disrupt the chefs by asking for additional items while they are cooking. So the business waits a bit until that food course is ready (sprint review), and gives feedback on the dishes they received. At this point, they add new desires and thoughts as they discover their tastes.
The Scrum Master is the Maître in this scenario. The Scrum Master facilitates the business meetings and ensures that the processes are followed to the restaurant’s (Scrum’s) standards. The Scrum Master is always looking for ways to improve the restaurant’s processes and ways to help the chefs with problems that occur. This is important so that the chefs focus solely on creating the food that was ordered.
As the customer prioritizes the menu, they decide what they really want. Does the main meal consist steak or swordfish? A simple salad? Do they want them all? Do they have the room in the budget for everything? What if they do not know yet what they want? Let’s say they thought they wanted a burger originally but developed a taste for surf and turf as the evening went on.
That is a huge complication in traditional management, but not in Scrum. However, the customer needs to be aware that it takes longer to prepare surf and turf and that it is more expensive than a burger. It will add more effort points (time/money) to their order (product).
Scrum breaks the project into sprints and does planning at each one of these sprints. This is done so the project can adapt to emerging desires. Emerging desires could be new discoveries in tastes, organizational processes, emerging technologies, business environment factors, etc. The food is brought out in courses or (sprints). In sprint 1, the course may be the appetizers. Then the customer decides what it wants next in Sprint 2. Sprint 3 they decide the subsequent course and so on.
After a sprint, as the business enjoys the product, they communicate with the restaurant staff their thoughts on that particular course during the sprint review. This would be as if the entire staff including the chefs came to the table to present the food and gather feedback- great restaurant, right?! Then they make decisions on the best way to adapt the product to their newly discovered tastes.
In traditional waterfall or project management methodologies, the customer pre-orders food and does not easily have the ability to change their mind. At least not without quite a lot of hassle. The Scrum method works really well when the customer does not know exactly what they are hungry for, or there are a lot of unknowns in what exactly they want for their meal.
The mass movement to the Scrum framework is due to Scrum allowing for an adaptable and transparent plan. Accountability is shared throughout the project creating an atmosphere of communication and collaboration. As new discoveries are made and previous unknowns become clear, the Scrum plan is simply adapted to accommodate the new desires.
For more insights into the Scrum, check out Clearly Agile’s site at www.ClearlyAgileInc.com. Based out of Tampa, FL
About the Author: As a Technical Scrum Master, it might be surprising that I am not technically inclined. After years in Project Management, I converted to Agile and the Scrum framework after I discovered the real value in adaptation, communication, and transparency. Rachel Schumacher PMP, CSM