Product Owners in Scrum: How to Get Started?
Epics, Stories, Themes, and Initiatives
In Scrum, Product Owners (POs) must complete certain preparatory tasks before the Scrum Team can begin working. This involves creating and defining a list of application "features." In Scrum terminology, these "features" are categorized as Epics and Stories. Additionally, in tools like Jira and Agile, you'll encounter Initiatives and Tasks.
Understanding Stories
In most software development projects, we typically consider "features" in terms of specific functionalities within the system. For instance, functionalities like providing a button to save a PDF file, allowing users to save it as a new PDF (Save As), or enabling PDF file uploads with options to specify page ranges for splitting the file. However, in Scrum, the focus shifts from features to Stories, which represent the user's perspective. POs need to convey Stories by addressing three key points:
For example, instead of simply stating, "allow the user to upload a PDF file and specify the page ranges to split the file," a PO might frame it as:
As a member, I want to split my PDF into two or more files so that I can have some pages as independent files and other pages as separate documents.
The goal is for the PO to share the user story, allowing the development team to explore the best solutions. Scrum emphasizes leveraging the intelligence of the development team, which is believed to generate innovative solutions. For example, rather than creating several text boxes for users to specify page ranges, the development team might propose a drag-and-drop interface for a more interactive experience. Ultimately, the implementation depends on the team's skill set and confidence in their proposed solutions. Therefore, the structure of a Story should be:
As [a user role], I want to [what to achieve] so that I can [the result].
Definition of Done
Every Story should include a "Definition of Done" (DoD). The PO must outline specific criteria for the development team to reference when determining whether their implementation meets user expectations. For instance, the DoD for the previous story might include:
While these requirements are general, the PO can detail additional expected features, such as:
The Definition of Done can also include specific design requirements, such as color schemes. Although the aim is to foster creativity within the development team, the PO must establish baseline expectations. Even with a defined DoD, the development team may negotiate requirements with the PO during Scrum Planning meetings and throughout the implementation phase.
The PO can also list "good-to-have" features within the Definition of Done.
Sprint and Sprint Goals
Over time, the PO will accumulate a substantial list of Stories. It’s important to note that not all Stories need to be ready before the project begins. New ideas may arise, prompting the PO to add Stories throughout the project lifecycle. However, a minimum requirement exists: ensure enough Stories are available for the upcoming Sprint.
A Sprint is a defined period for a cycle of development work. In Scrum, it is crucial that all team members deliver a workable software product by the end of each Sprint. This means the software must be ready for the user to interact with.
You may wonder how we can deliver a product in the first Sprint, particularly if it lasts only a week. The answer is yes; we must deliver workable software each week. The key lies in prioritizing what needs to be delivered, which is where the Product Owner plays a vital role. It’s the PO's responsibility to identify the most critical items for end users.
For software to be considered workable, it should have a designed UI, implemented Stories, and completed testing—all requiring collaboration between UI/UX designers, developers, and QA engineers.
To ensure the team stays focused, it’s essential for the PO to define a Sprint Goal for each Sprint. This goal provides direction for what the team aims to achieve during that period. For example, in a digital signing software project aimed at replicating a system like DocuSign, the PO must determine the most essential features to deliver in the first Sprint. For instance, a suitable Sprint Goal could be: Able to process a complete sign request with minimal facilities. This is vital to ensure users understand the digital signing process.
At the end of the first Sprint, the development team may deliver the entire signing workflow, including adding recipients, placing signature fields, sending emails, and enabling self-signing of documents.
Once a Sprint Goal is defined, the PO can prioritize Stories related to that goal and elevate them on the backlog. For instance, a Story focused on "Add Recipient" might initially only require basic functionality, such as two text boxes for "name" and "email." In subsequent Sprints, the team can refine and enhance this feature by supporting multiple recipients, implementing sequential or parallel workflows, or adding drag-and-drop functionality for reordering.
As a PO, I often established Sprint Goals (and even goals for the next few Sprints) before creating Stories. I would customize Stories specifically for each Sprint, while simultaneously adding new ideas to the backlog to avoid forgetting them.
Backlog Management
When a PO develops a new Story, it should be added to the Scrum Backlog, which is essentially a list of Stories awaiting action from the Scrum team. When adding Stories, it’s crucial to maintain their order based on importance. High-priority Stories should be placed at the top of the Backlog, with the understanding that their priority may shift over time.
During the initial Sprints, Stories generally cover high-level implementations. As the project progresses, we will delve into more refined features associated with specific Stories.
During Scrum Planning meetings, the PO will review the top Stories in the Backlog with the development team. Each team member must understand the Stories and seek clarification on any missing details from the PO. The PO may revise the Stories during this discussion to ensure they are complete. Team members will then provide their estimates for each Story. Once several Stories have been reviewed, the team will assess whether the total estimated time aligns with the available capacity for that Sprint.
It’s essential to emphasize that it is the development team members who decide which Stories to include in each Sprint. When selecting Stories, they must ensure they can achieve the Sprint Goal. Therefore, Stories must be manageable in size, so adding one does not necessitate including multiple others just to achieve the Sprint Goal. The PO can revise the Sprint Goal during planning meetings, but this should be approached with caution. The PO should have sufficient knowledge to define Sprint Goals and Stories based on what can realistically be accomplished within the Sprint.
This understanding develops over time through project implementation, and POs can seek guidance from the Scrum Master and development team members. Ideally, the Scrum Master assists the PO in defining Sprint Goals and Stories by communicating with each team member to gauge their capabilities. Even without initial estimates, POs, Scrum Masters, and development team members can better understand the overall performance of the Scrum team, which is the purpose of having Sprints in Scrum.