No Scrum Standards, Only Practices
Product Owners: How to Get Started?
Epics, Stories, Themes, Initiatives
In Scrum, there are some preparation works to be completed by Product Owners (PO) before the whole Scrum Team can get started. In short, a list of application "features" will need to be listed and defined. In Scrum, the "features" are defined as Epics and Stories. In Jira and/or Agile, there are also Initiatives and Tasks.
Please have a quick look on what the experts shared: Epics, Stories, Themes, and Initiatives | Atlassian
Please also Google search for a better definition or examples of Epics and Stories, while please don't mind me share our experience below.
Please have a quick look on what the experts shared: Epics, Stories, Themes, and Initiatives | Atlassian
Please also Google search for a better definition or examples of Epics and Stories, while please don't mind me share our experience below.
Stories
In most software development projects, we always look at "features" in terms of a feature in the system, e.g. provide a button to save a pdf file, provide a button to save the file as a new pdf file (the Save As), allow the user to upload a PDF file and specify the page ranges to split the file. In Scrum, instead of features, PO requires to define or tell the Stories. Stories are the users' stories. Trying to tell the Scrum team what is the story is, from the user's point of view, in three ways:
The objective is for PO to tell the story and let the dev. team to look for the best solution. Scrum wants to use the brain power of the dev. team. It is believed that the dev. team can come up with many good solutions as they are the smart guys and they have lots of brain power. As in the example above, instead of creating a few textboxes for users to specify the page ranges as specified in the "feature", the dev. team may come up with a drag-and-drop interface for a more interactive experience. Of course, the final implementation depends on the skillset of the dev. team and depends on whether they are confident to develop the solutions that they are purposing. Apparently, it should not be the PO or any others can tell, but the dev. team members themselves should. Therefore, the syntax of the Story is like:
- Who are the users telling the story or what is their role?
- What the users are trying to achieve?
- What is/are the expected result(s)?
- As a member, I want to split my PDF into two or more files so that I can have some pages as an independent file and other pages as another file.
The objective is for PO to tell the story and let the dev. team to look for the best solution. Scrum wants to use the brain power of the dev. team. It is believed that the dev. team can come up with many good solutions as they are the smart guys and they have lots of brain power. As in the example above, instead of creating a few textboxes for users to specify the page ranges as specified in the "feature", the dev. team may come up with a drag-and-drop interface for a more interactive experience. Of course, the final implementation depends on the skillset of the dev. team and depends on whether they are confident to develop the solutions that they are purposing. Apparently, it should not be the PO or any others can tell, but the dev. team members themselves should. Therefore, the syntax of the Story is like:
- As [a user role], I want to [what to achieve] so that I can [the result].
Definition of Done
Apart from the above title, each story should come with a "Definition of Done". PO must specify the requirements for the dev. team so that they can refer to this Definition of Done to determine if their implementation satisfy the user to complete the story. For example, the Definition of Done of the above story might be:
PO can also specify a list of "Good-to-have" features in the Definition of Done.
- Allow users to upload one or more documents with extension PDF;
- Allow users to specify or select a set of pages in form of page numbers or page ranges - "set of pages";
- Allow users to specify one or more "set of pages".
- The System shall split the PDF document and generate a PDF document for each "set of pages" specified;
- Allow users to download the generated document(s);
- Other than page range text boxes, the System shall provide an alternative UI to allow users to drag-and-drop the pages into a placeholder;
- If multiple "set of pages" are specified, the System provide the option to download the resulting PDFs as individual files (default) or as a zip;
- Allow users to specify the name of each resulting file, while the default file name is [original file name]-1, [original file name]-2, and so on.
PO can also specify a list of "Good-to-have" features in the Definition of Done.
Sprint and Sprint Goal
From time to time, PO can build up a large list of Stories. This list of Stories do NOT need to be ready before the project starts. There are always better ideas from time to time and PO will add stories throughout the project life cycle. There is a minimum requirement though: make sure there is enough stories for the upcoming Sprint.
A Sprint is simply a well defined period - a cycle of development works. In Scrum, it is exceptionally important that all members must deliver a workable software at the end of each Sprint. For workable software, it means the software can actually deliver to the user and start working on it.
Yes, at this point, you may wonder how can we deliver something on the 1st Sprint, especially we are having one week Sprint. Does it mean we need to deliver a software in one week?
Yes, we need to deliver a workable software in one week and every week thereafter. It is possible. It is a matter of what we need to deliver - and this is why we need a Product Owner, you. You have to tell what the most important to deliver to our end user first.
And for workable software, we mean the software is supposed to have UI designed, stories implemented and tested - which involves UI/UX designers, developers and QA engineers.
Due to the fact that the team must deliver a workable software at the end of each Sprint, it is important for PO to define a Sprint Goal for each Sprint, so that the team know what they are looking to achieve in each Sprint. With a clear goal, the whole team are running towards that goal.
For example, in the digital sign software project, imagine the PO is to deliver a complete system like DocuSign and it involves lots of UIs and features. What should the PO deliver in the first Sprint? What features are the most important for the end user? The Sprint Goal of the first Sprint I defined was: Able to process a complete sign request with the minimal facilities. As a PO, I believe it is very important to have a complete workflow for the signing process so that the end users can understand how the digital signing works. At the end of the firrst Sprint, the dev. team delivered the whole process from adding recipients, adding signature field, sending an email and self-sign the document.
When a Sprint Goal is defined, PO can add the Stories related to the Sprint Goal and move to the top of the list. In the above example, a Story is related to "Add Recipient". Instead of supporting multiple recipients, supporting features like sequential or parallel workflow, drag-and-drop feature to reorder the sequence, the "Add Recipient" in the first Sprint is just to provide two textbox "name" and "email". Also, "Adding Signature Field" is just to add one text field, "sending an email" with hard-coded content instead of using a template, "self-sign" instead of sending another user to sign because there is no user login at the first Sprint. The Stories only cover the high level implementation.
In fact, when I was a PO, I first defined the Sprint Goal (or even the goals of upcoming two or three Sprints) before working on Stories. The Stories I defined are tailor made for the specific Sprint. At the same time, whenever a new idea come up my mind that I believe the product should have, I will also add them to the Backlog immediately so not to forget about it.
A Sprint is simply a well defined period - a cycle of development works. In Scrum, it is exceptionally important that all members must deliver a workable software at the end of each Sprint. For workable software, it means the software can actually deliver to the user and start working on it.
Yes, at this point, you may wonder how can we deliver something on the 1st Sprint, especially we are having one week Sprint. Does it mean we need to deliver a software in one week?
Yes, we need to deliver a workable software in one week and every week thereafter. It is possible. It is a matter of what we need to deliver - and this is why we need a Product Owner, you. You have to tell what the most important to deliver to our end user first.
And for workable software, we mean the software is supposed to have UI designed, stories implemented and tested - which involves UI/UX designers, developers and QA engineers.
Due to the fact that the team must deliver a workable software at the end of each Sprint, it is important for PO to define a Sprint Goal for each Sprint, so that the team know what they are looking to achieve in each Sprint. With a clear goal, the whole team are running towards that goal.
For example, in the digital sign software project, imagine the PO is to deliver a complete system like DocuSign and it involves lots of UIs and features. What should the PO deliver in the first Sprint? What features are the most important for the end user? The Sprint Goal of the first Sprint I defined was: Able to process a complete sign request with the minimal facilities. As a PO, I believe it is very important to have a complete workflow for the signing process so that the end users can understand how the digital signing works. At the end of the firrst Sprint, the dev. team delivered the whole process from adding recipients, adding signature field, sending an email and self-sign the document.
When a Sprint Goal is defined, PO can add the Stories related to the Sprint Goal and move to the top of the list. In the above example, a Story is related to "Add Recipient". Instead of supporting multiple recipients, supporting features like sequential or parallel workflow, drag-and-drop feature to reorder the sequence, the "Add Recipient" in the first Sprint is just to provide two textbox "name" and "email". Also, "Adding Signature Field" is just to add one text field, "sending an email" with hard-coded content instead of using a template, "self-sign" instead of sending another user to sign because there is no user login at the first Sprint. The Stories only cover the high level implementation.
In fact, when I was a PO, I first defined the Sprint Goal (or even the goals of upcoming two or three Sprints) before working on Stories. The Stories I defined are tailor made for the specific Sprint. At the same time, whenever a new idea come up my mind that I believe the product should have, I will also add them to the Backlog immediately so not to forget about it.
Backlog
When PO comes up a Story, PO should add the Story to the Scrum Backlog. Backlog is simply a list of Stories pending for the Scrum team to handle. When adding a Story, it is important that the order Stories must be maintained based on importance. So, PO can add a Story at the beginning of the Backlog if it is highly important. Note that the priority of each Story can change any time in the Backlog.
At the beginning, i.e. the first few Sprints, the Stories were to cover high level implementation of Stories. In later Sprint, we will provide more enhanced features of a specific feature/Story.
In the Scrum planning meeting, the PO will go through the Stories on the top of the Backlog. Every members in the Dev. Team must understand the Story and clarify any missing details with the PO. PO may revise the Story at that point to make it more complete. Then dev. team member will give their own estimation on each story. After going through several Stories, it will stop if the team believes the total estimated time is what enough to be covered in that Sprint.
It is very important to note that it is the Dev. Team members who decide which Stories to add to each Sprint. When adding Stories to the Sprint, the dev. team members must make sure the Sprint Goal must be achieved. Therefore, the Stories must be "small" enough so that it won't be adding, say, three stories but which two other stories must also be added to achieve the Sprint Goal. Note that it is also possible for the PO to revise the Sprint Goal during the Scrum Planning meeting but it should be avoided. Saying so, it means the PO should have some knowledge when defining Sprint Goals and Stories on what can be completed with the Sprint. This depends on the experience of PO and his understanding on the team's performance. While this experience can be built up from time to time during project implementation, PO can always seek for advices from Scrum Master and Dev. Team members. Ideally, the Scrum Master is able to guide the PO on defining Sprint Goals and Stories as, when I was the Scrum Master in teams, I will also talk to each development team members to understand their capability. Even without the initial estimation, PO, Scrum Master and dev. team would understand the performance of the whole Scrum team better and better and this is why we have Sprints in Scrums.
At the beginning, i.e. the first few Sprints, the Stories were to cover high level implementation of Stories. In later Sprint, we will provide more enhanced features of a specific feature/Story.
In the Scrum planning meeting, the PO will go through the Stories on the top of the Backlog. Every members in the Dev. Team must understand the Story and clarify any missing details with the PO. PO may revise the Story at that point to make it more complete. Then dev. team member will give their own estimation on each story. After going through several Stories, it will stop if the team believes the total estimated time is what enough to be covered in that Sprint.
It is very important to note that it is the Dev. Team members who decide which Stories to add to each Sprint. When adding Stories to the Sprint, the dev. team members must make sure the Sprint Goal must be achieved. Therefore, the Stories must be "small" enough so that it won't be adding, say, three stories but which two other stories must also be added to achieve the Sprint Goal. Note that it is also possible for the PO to revise the Sprint Goal during the Scrum Planning meeting but it should be avoided. Saying so, it means the PO should have some knowledge when defining Sprint Goals and Stories on what can be completed with the Sprint. This depends on the experience of PO and his understanding on the team's performance. While this experience can be built up from time to time during project implementation, PO can always seek for advices from Scrum Master and Dev. Team members. Ideally, the Scrum Master is able to guide the PO on defining Sprint Goals and Stories as, when I was the Scrum Master in teams, I will also talk to each development team members to understand their capability. Even without the initial estimation, PO, Scrum Master and dev. team would understand the performance of the whole Scrum team better and better and this is why we have Sprints in Scrums.
