In the previous article, you’ll find a definition of the roles in this Scrum implementation.
This article discusses:
- Epics
- Stories
- Tasks
… and how they form the Backlog and get assigned to Sprints.
Epics
Epics are a collection of stories that, when combined, form a meaningful outcome. An example might be “Release the Beta version of the Product”. A team usually works on one Epic at a time, but this can vary depending on team size and number of systems.
Stories
A story defines an outcome of value. Stories must be written in the form “As a {entity such as customer, system or employee}, I should be able to {do something}, so that {benefit/value}”. It’s a good idea to make the titles of stories concise for quick recognition when viewed in a list.
Stories must also include a list of acceptance criteria that removes all ambiguity for the contributors.
An example story:
Story Title: Social icons on all pages
As a customer, ISBAT click social icons on the site to promote the page content to my followers. This will help spread the word of our awesome product through social networks and will help with search engine rankings, driving even more traffic to our site.Acceptance Criteria
- Facebook, Google Plus and Twitter icons on all pages
- Positioned both in the header and footer of all pages
- Must use best industry practices for performance
- Must use company approved icon styles
Story Size: TBD
Stories must be sized. Story sizing is done by the SM and the Contributors together. Use the Fibonacci sequence; each story is size 1, 2, 3, 5, 8, 13 or 21. The size of stories is based on complexity, not hours. Each team will naturally gravitate towards a common understanding of the level of complexity each number in the Fibonacci sequence represents. It’s a little rough at first, but after a few Sprints, everyone is in sync. More on story sizing in the next article.
Velocity is the number of story points a team can do in a Sprint. Figuring out team velocity is a little rough at first too, then becomes very predictable.
Tasks
Tasks are a list of items that must be done to satisfy the acceptance criteria. These are usually not defined until the Sprint Planning meeting. For the Sprint about to start, the SM and Contributors go through each story assigned to the sprint and define the tasks. This can be done on notecards, we call this analog, or electronically, with software.
Backlog
All stories start out in the Backlog. The Backlog is nothing more than a list of all the stories not yet started or assigned to a Sprint.
The Backlog should be in priority order. It’s up to the PO to ensure the Backlog is always in priority order. The PO should also ensure all stories have adequate acceptance criteria so the SM and Contributors can properly size them.
Sprints and Backlog List
Here is what the Sprints and Backlog list might look like:
There is a lot of software out there to assist tracking this. I’ve used JIRA, it works. If all team members are in one place, I’d recommend starting with notecards, markers and pinboards. It’s important to form your process first, then find software that will assist and accelerate the way you work. Process before tools.
The Outcome
If all stories in the backlog are sized and in priority order, and the team velocity is known, the PO can see how long it’s going to take to get to any item on the Backlog. The PO can do this at a glance. He/she can also immediately understand the consequence of changing the priority or injecting a new story into the backlog.
Also, the cadence of Scrum provides comfort to its members. Once you have a system in place for how you do your work, you can rely on it, and spend the majority of your time doing the work, and less time worrying about the process.
In the next article, will unravel the mystery of Story Sizing in great detail.