Agile / Scrum process
An Agile / Scrum product flow consists of a number of objects:
Product
A product might contain the themes, epics, and stories that describe these enhancements from the user’s perspective. Products can have a narrow focus with few user stories or a wider context with many user stories, each containing several tasks. You create products first and then add themes, epics, or stories to create the product backlog.
(Product) Release
A product release resembles an iteration of a product. The first iteration is iteration 0. A product release has a start and end date during which a number of development iterations are completed. When a product release is set, at least one project team and its members should also be created.
Sprint
A sprint is the basic unit of time in the development process.
A sprint typically covers between one and four weeks to finish. The product owner creates one or more sprints from within a release. All sprints within a release must fit within the release start and end dates. The project team is expected to complete all stories to which it is committed within a sprint and to meet the acceptance criteria as defined in the story records. The product owner’s expectation of the sprint content is that the stories are fully tested and potentially releasable. In most cases, the committed stories for a specific sprint should not change during the sprint. Stories should be added or removed from a sprint only after a discussion with the team by the product owner.
(User) Story
A user story is simply something a user wants i.e.: “As a <type of user> I <need> so that <benefit>.”
User Story – Acceptance Criteria attribute
A user story typically has acceptance criteria attributes. Acceptance criteria are requirements that need to be met in order for the user story to be considered completed. These requirements in turn can be used to specify validation statements that can be used in system integration testing (SIT) or user acceptance testing (UAT).
User Story – Story Points attribute (“Size”)
Within the Agile / Scrum framework estimation of work is not normally done in terms of time – a more abstracted metric to quantify effort is used. Common estimating methods include:
- Numeric sizing (1 through 10),
- T-shirt sizing (XS, S, M, L, XL, XXL, XXXL),
- Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.).
Each user story is assigned a value. The value indicates how complex the user story is to implement. This value is referred to as the user story points value, or more commonly, the user story “size”.
Important is that the team shares a common understanding of the scale it uses, so that every member of the team is comfortable with it. A popular approach is to use the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, (21, 34, 55, 89). The reason for using the Fibonacci sequence is to reflect the uncertainty in estimating larger items. A high estimate usually means that the story is not well understood in detail or should be broken down into multiple smaller stories. Smaller stories can be estimated in greater detail. It would be a waste of time to discuss if it is 19, 20 or 25; the story is simply (too) big.
User Tasks
Typically, stories are expressed in plain language to help the reader understand what the software should accomplish. Product owners create stories. Stories can be divided into one or more tasks. Tasks are the discreet pieces of work required to complete a story.
Planning
Rather than estimating how much time it takes to complete an certain amount of work, we estimate how much work we can complete in a fixed amount of time (i.e. a sprint). To help this process, it is recommended to keep the amount of time for each sprint or release constant.
Velocity
Before a sprint starts, the team and product owner decide on what stories they can commit to completing within a sprint. In order to estimate how much user stories we can complete in a sprint or set of sprints (release), we simply look at the total of the story points of any previous sprint(s).
The velocity of a team is the total of all story points of a sprint the team has completed in the past.
The product owner must make sure that the effort (story points) required to complete the stories matches the capacity of the release team. If the effort exceeds the capacity, the product owner can add team members, remove stories, or remove sprints as needed.
Theme
To further help with planning, we can use themes. A “theme” is collection of user stories. We could put a rubber band around that group of stories and call that a “theme.” Themes are high level abstractions of product functionality.
Epic
An “epic” is just a big story (large size value) that needs to be broken down into smaller stories so that we can write fitting acceptance criteria. An epic describes a block of requirements that have not yet been rationalized into stories. An epic can have one or more stories, but a story can belong to only one epic at a time.
Kanban Board
A Kanban board is a work and workflow visualization tool that enables you to optimize the flow of your work. Physical Kanban boards, like the one pictured below, typically use sticky notes on a whiteboard to communicate status, progress, and issues.
Using a physical whiteboard (above) is vibrant and works well in (stand-up) meetings. Using a software product (below) allows for advanced actions like grouping, zoom in/out and expand/collapse.
