Four years ago, Devbridge adopted Scrum as a process for driving development. I was there from the beginning. I confess that I didn’t have any knowledge or interest in driving or knowing how to drive development effectively at that time—I was just a developer who liked developing.
It was all new to me, as well as those I was working with. To my surprise, my first role was more like that of a product owner (PO)—I acted as a bridge between the client and the team in preparing backlogs, keeping both happy. I learned that user stories must meet INVEST principles.
I was lucky to have several lengthy projects with full and stable teams, and clients who were willing to learn how to work using Scrum. Because of this, I’ve learned what it means to work with a team that is growing while following Scrum principles. In these environments, team members are engaged and own the software they’re building. Daily development processes are so simple that there’s no need to manage tasks—there’s no need for a “lead” who tells everyone what to do and which tasks to take.
In this post, I’ll share some of the things I’ve learned that can help to build better backlogs and engage the development team. To not just build products, but own them.
Whole product backlog or V1 story estimation
At the kickoff, the product manager (PM) and team should agree on the Definition of Ready (DOR) and the Definition of Done (DOD). After both are defined, it’s a great time to estimate the whole available backlog, or some V1.
Since the story mapping usually happens before development begins, the PM should have one available. The estimation meeting is usually avoided for a few reasons: The meeting can take considerable time, teams might not be prepared, or the development team for the project hasn’t yet been formed.
Still, in my experience, having an estimation meeting can provide the following benefits:
PMs have the chance to evaluate how well they understand the problem and scope. In other words, the shape of backlog becomes clearer.
Playing the estimation game requires that all team members understand the scope and be active participants. By asking questions, the team helps to clarify requirements and makes progress toward owning the project.
We get estimates early in the project, enabling us to track and predict the end of the project when team velocity is established.
How it should happen:
The PO should be ready to present scope, with an emphasis on introducing the “valuable” principle of the INVEST mnemonic. In my opinion, this should be primarily the responsibility of the PO, as all other principles could be covered by the Scrum team. Of course, the better stories adhere to INVEST principles, especially independent, small, and testable, the smoother the meeting will go. This is important because it’s difficult for team members to focus on stories that aren’t clearly defined.
At this time, it’s perfectly fine to have a list of stories with short descriptions (results from story mapping work, too), as long as the PO is prepared to verbally present it and answer the team’s questions.
No backlog editing should happen during this meeting. Doing so would require the whole team to be present, meaning it’s expensive. It’s also easy for the team to lose focus if the meeting isn’t run effectively.
Other Sprint 0 activities
Now that we’ve gathered the development team, the PO has presented the scope, we’ve estimated most of the work, and we have some high-level understanding, what’s next?
Without stories or a defined DOR, that can be tricky.
For example, with quality assurance (QA), since nothing has been developed, what can we test? My answer: QA could and should contribute from the beginning and can take work from our POs. QA can also write acceptance criteria (AC), contributing to the testable principle of INVEST.
It’s common for POs to write acceptance criteria during grooming or planning meetings. This takes away precious time from the meeting and from teams, which shouldn’t happen. It’s wrong to write and fix story definitions during meetings with the whole team. QA can help with this by writing and modifying story definitions after the meeting. Story descriptions can be short, so long as the PM is able to clearly explain it to the team during grooming. Later, QA can fill the acceptance criteria. My suggested Sprint 0 activities are:
PO refines the backlog, ideally within a week of when the first stories meeting DOR gets created
QA helps the PM to refine backlog by writing AC
Designers create a style guide for project and prepare assets for the first user stories
Developers focus on setting up the project structure, continuous integration, tools, and common components. Developers should also work with designers to clarify what is needed for the style guide
Most importantly, the entire team helps the PO to refine backlog stories by estimating, asking questions, and contributing to the INVEST principles independent, estimatable, and small
My experiences has led me to believe that having these small things—initial backlog grooming, investing in engaging a team into building the backlog, and QA writing AC with story input from the team—we can shorten the overall time needed for POs to spend with the development team. Having just two effective grooming and planning meetings is enough. There’s no need for daily standups with POs, which I fear becomes more and more common practice.