What I learned, unlearned and relearned at a Product Owner bootcamp
I recently got my CSPO training and certification and my head is still abuzz with the information overload that was delivered over the course of a weekend. I went in brimming with confidence from having worked as a developer and devops engineer on agile projects throughout my career. But I quickly swallowed my pride when I got ALL my answers wrong on the first spot quiz of the day.
Turns out, most projects are not really agile but follows more of a ‘scrum-fall’ methodology to accommodate the whims and demands of the clients. A lot of my previous notions were challenged and corrected. These are the biggest ones.
Sprints are individual projects
Yeah, seems anti-pattern, doesn't it? After having worked on scrum teams throughout my career, I was taken aback when we learned that each sprint is a project. My earlier assumption was that each project consists of sprints, which we complete to reach the project’s end goal. That is completely wrong. The justification is that the PM is responsible for orchestrating the team to complete each sprint on time while contributing to the end product. Very similar to how we treat projects in the IT sector. To make this simpler, treat scrums with respect to Products, not Projects (from the traditional IT sector). The below comparison image would make it even easier to grasp:
No User Stories, Tasks or Priorities
Another shocker! If you have used any popular scrum boards (Jira, Azure, Aha), you may have come across these 3 terms sometime during your stint. However, the latest Scrum Guide (or any scrum guides for that matter) does not mention these keywords even once. Simply because in a true scrum world, they don't exist. What we have experienced are a slightly customized version of true scrum to accommodate our product objectives. Which is fine, but it is not Scrum.
User Stories originated from Extreme Programming and look like this
In complex product development, it becomes harder to write such stories and the stories themselves become unnecessary long. Who wants that? What does this user want? Why does this user want that? These are some questions that become gradually difficult to put down. And these requirements become too broad to achieve in a sprint. It borders dangerously close to Epics. So instead of using User Stories, break down your requirements into Product Backlog Items, which are small achievable modules for your sprint. You can use formats to write down your product backlog items that make sense for your context. These could be simple texts, bullets or hypotheses to explore.
Also, since you are already using PBIs now, why do you even need Tasks? Scrum doesn't support micro-management and assigning Tasks to team members is doing just that. The accountability should be at the PBI level, assigned to individual Teams or Persons.
It's not priorities, it’s Priority. Singular. The next question was how then do we prioritize our work? You don't. You order them. If you're already using PBIs, your backlog is already ordered from work-due-longest to work-last-assigned. And that's your priority list.
Decrease Output
Again, this sounds anti-pattern but what it is essentially saying is that reduce your output while increasing your outcome. This means increasing your ROI. Your output is a direct result of your inputs. So reducing your output is telling us to reduce your inputs. However, your returns should not suffer. The below graphic sums it up nicely.
In essence, this is hitting both the top margin and bottom margin. Use scrum to push your returns (sprint goals) higher while pulling down your investments (in terms of time and team members count).
An increase in a team’s velocity does not mean they are going faster. It often means they are going smarter. As teams work together, they reduce wasteful decisions. They also develop innovative shortcuts or high-quality teamwork. Thus one of the ways a team increases their velocity is BY DOING LESS WORK. As a team travels through their backlog, they will discover ways to reduce work per Product Backlog Item. They’ll figure out ways to automate a bunch of repetitive stuff; they’ll produce modular designs which create opportunities for reuse and adaptation; they’ll learn from their mistakes, reduce risk, and increase quality.
In other words, the team finds ways to travel further through their backlog each Sprint while not working harder/more.
Variable Scope, Constant everything else
Another important takeaway from the Bootcamp was what to fix at the very beginning of our sprints. On the top of the list is Quality. Earlier models never focussed on fixed quality. Agile changes that by keeping not only quality constant but also the time, the budget, the goals of the Sprint and even the Team members.
As you can see, it is expected that the scope of work will change. But the quality should not be compromised. This means also accepting the fact that sometimes (keeping time constant), the sprint may not complete all PBIs. But whatever it does complete, the quality of work should be maintained.
I realized that most of my concepts were derived from working on traditional long-term IT service projects. A great analogy that the trainer used to solidify this difference was
Project is like pregnancy, it has a beginning and an end; you deliver on time, on budget, and on scope
Product is the child; development never stops.
I also learned a whole bunch of other important concepts like shifting left, dynamic product backlogs and balancing priorities and needs. But, I can't possibly cover them all in one blog post. That won't be very agile.
