Product Backlog Items: Difference between revisions

From AgileMe
Jump to navigation Jump to search
 
(4 intermediate revisions by the same user not shown)
Line 5: Line 5:


==User Stories==
==User Stories==
User stories although not part of the core Scrum framework, are a very popular form of PBI and are intended to be conversation reminders, with the name “User Story” relating to how they are used in conversation rather than how they are written.
[[User Stories]] and Epics although not part of the core Scrum framework, they are a very popular form of PBI with [[Scrum Framework|Scrum]] teams and are intended to be conversation reminders, with the name “User Story” relating to how they are used in conversation rather than how they are written.
The first value in the Agile Manifesto describes “Individuals and Interactions over Processes and Tools”, hence User Stories are intended to bring people together to interact and discover what the feature needs to be, rather than as a replacement for written requirements.


===Structure===
==Tasks==
Most User Stories will have a name or index number for easy reference and may also have sizing or estimates to indicate the amount of effort to complete them.
Another form of PBI is a simple task that may only indicate the name of the feature or work item to be built. This very simple approach tends to be used by more mature teams that have learnt to continuously collaborate and communicate with each other to thoroughly understand what is required, and all that is needed is a simple reminder for them to understand the context for the task.
A common format for the main bod of User Stories:
 
* '''As A <nowiki><Actor / Recipient></nowiki>'''
* '''I Want <nowiki><Some Feature></nowiki>'''
* '''So That <nowiki><Reason / Context></nowiki>'''
 
An additional section is also added to cover the Acceptance Criteria:
 
Acceptance Criteria:
'''<nowiki><I Know It’s Done When … ></nowiki>'''
 
====Gherkin Format====
User Stories that are used for Test Driven Development practices often employ the Gherkin format for the acceptance criteria rather than unstructured statements:
 
* '''Given <nowiki><Some Pre-condition></nowiki>'''
* '''When <nowiki><Some Action></nowiki>'''
* '''Then <nowiki><Expected Outcome></nowiki>'''
 
This provides a set of testable expectations in the User Story that can then be used for feature definitions and generating step definitions.
 
===Granularity===
User Stories should also be at an appropriate level, too high such as a Use Case for example, and they will be quite meaningless and take a long time for a team to complete them. Too detailed, and this will replace the conversation with written assumptions about what the feature should be.
Good user stories are somewhere between the high level of a Use Case and the detail of a business requirement, and should relate to a work objective or feature to be delivered.
Initially, it is quite normal for User Stories to be quite high level, as we don’t know very much about them. Over time, however, User Stories may start to be broken down and split into smaller User Stories that are more consumable by a team as more is known about the item or feature.
 
===Testable===
User Stories should relate to a feature or item to be delivered, and a good validity check is to ask it is testable. For example, if a User Story that states “As a User I want the web page to be easy to use so that it isn’t too complicated,” is going to be difficult to deliver as a discrete piece or work and harder to test in an objective sense. A User Story that states “As a researcher I want to search for web pages that match my criteria,” is more defined as a work item that can be tested and evaluated.
 
===Technical Items===
User Stories do not have to be just about the user, they can also be for architectural changes or other technical work objectives to be delivered. A good Product Backlog will have a range of User Stories that consider different user segments as well as technical items to be delivered as well, such as improvements to remove Technical Debt for example.
 
==Epics==
Epics are usually large features or categories of User Stories and are often used to provide a higher level context for a group of User Stories.
Used in Story Mapping for example, Epics are normally used to indicate the backbone of the Story Map and the main high level feature set. They are then broken down into multiple User Stories as granular work items under each Epic.


==One Tier vs. Two Tier Approaches==
==One Tier vs. Two Tier Approaches==

Latest revision as of 02:03, 20 December 2018


Product Backlog Items (PBIs) describe the work to be done and form a list of work objectives that are placed and ordered on the Product Backlog. They can take many forms with the most popular being epics, features and user stories. PBIs are normally taken from the Product Backlog during Sprint Planning and can be broken down further as the Development Team form their Sprint Backlog with consumable items that are testable and can be delivered within the Sprint.

User Stories

User Stories and Epics although not part of the core Scrum framework, they are a very popular form of PBI with Scrum teams and are intended to be conversation reminders, with the name “User Story” relating to how they are used in conversation rather than how they are written.

Tasks

Another form of PBI is a simple task that may only indicate the name of the feature or work item to be built. This very simple approach tends to be used by more mature teams that have learnt to continuously collaborate and communicate with each other to thoroughly understand what is required, and all that is needed is a simple reminder for them to understand the context for the task.

One Tier vs. Two Tier Approaches

After the Sprint Planning has been done there should be a selection of PBIs that have made it onto the Sprint Backlog. They may have been decomposed into smaller PBIs and split into something that is consumable by the team. One approach to take whilst working in a Sprint is a one tier approach, where there is one level of PBIs that form the work objectives to be delivered. This single level of PBIs are worked through during the course of the Sprint and are completed as a whole. Another approach is to use a two tier system, where the PBIs are broken down into PBIs and tasks. Tasks being a sub element of work to complete the PBI. Either system tends to work well with teams and usually depends upon the nature of the work and how comfortable the team are at breaking things down into more granular items.

Key considerations when deciding to use either system:

  • One tier works well when each of the PBIs are quite small, e.g. when using Planning Poker sizing and Story Points they may be in a range of 1 to 5 Story Points, with any items larger than this range broken down further into smaller PBIs
  • If using large PBIs in a one tier system, each PBI can take a long time to complete with little movement seen on the Sprint Backlog and in the metrics if using a Sprint Burndown chart for example. This can promote a lethargic approach to the Sprint and also obscure the team from inspecting their progress towards the Sprint Goal, as these large tickets don’t seem to be moving.
  • Two tier works well for teams that struggle a bit to break the work down and it makes sense for them to have PBIs that represent a work objective and that the tasks indicate the things to be done to achieve the objective. Here, the PBIs are generally at a high level and coarse grained.
  • If using metrics such as a burn down chart for example, then if using a one tier system, the burndown metric is based upon the size of the PBIs e.g. Story Points. If using a two tier system, then the burn down metrics would be based upon the sizing of the tasks e.g. hours, (assuming that the tasks are small enough that hours to complete them is appropriate.) The general intention is to provide a level of granularity for the metrics that show smooth curves as small items are completed. If large items are tracked, then this leads to large step changes in the metrics, which are not very helpful for a team to make choices during a Sprint.

See Also

Retrieved from "https://agileme.wiki/wiki/index.php?title=Product_Backlog_Items&oldid=902"