When building a new product or upgrading software, you need to prioritize your wants and needs and maintain a healthy development backlog.
This article is part 3 in a 5-part series explaining maximizing long-term throughput. Previously we discussed meetings and communication, and the key tenets of the development process.
What is a Development Backlog?
The development backlog defines what work will be performed by the design and development team. At SmartLogic, we build our development backlog with user stories in Pivotal Tracker.
Why a Development Backlog Matters
Of course, if you’re paying for their time, you want your employees/development firm to only work on high-priority items. You need to prioritize your developers’ work to align with your customer/stakeholder needs and your overall business agenda.
Tactics vs. Tools
Below, we outline the tactics we use to manage the development backlog along with suggested tools. Tactics are the pillars of the process and change on an infrequent basis (e.g. every several years).
The tools, on the other hand, are mutable. They can and should change as better or more convenient tools and software products become available.
| Tactics | Tools |
|---|---|
| Write user stories (more on this below) in a commonly understood language and in a consistent format. | We use the Gherkin format to write user stories. |
| Keep track of the list of user stories and their relative priorities. | Though they may start on a whiteboard or index cards, we eventually document all user stories and their relative priorities in Pivotal Tracker |
| Go through the life cycle of a user story from conception (writing it with the team) to full-grown independent adulthood (deployed to production) | Pivotal Tracker does a great job tracking the life cycles of user stories. |
| Have the product owner accept or reject all delivered stories. | Automated email notifications are sent to the product owner as stories are delivered. |
What’s Pivotal Tracker
Pivotal Tracker documents all features and bugs and is a running portrait of what is in the project. Your live product is the summation of everything in Tracker.
User Stories
Essential for a smooth development process, user stories are the most atomic units of describable work that developers and “business” people alike can understand. User stories are the common language understood by both developers and non-developers. Developers ultimately write code to implement user stories.
We use the Gherkin format for writing user stories:
In order to \<do something of value\>
As a \<user type\>
I want to \<perform some function\>
User stories are added to the development backlog, which is a list, ordered by relative priority, of user stories. If a user story is on the backlog, it is on the development schedule. If a user story isn’t on the backlog then the developers will not write code implementing the user story.
Developers should write user stories in a consistent manner and so that all technical complexities are considered. Being thorough allows developers to assign accurate estimates to the user stories.
Estimating User Stories
Part of writing user stories is estimating the complexity of writing code to implement the story. This helps you plan development and design time, as well as budget costs for a given set of work.
User stories are assigned “point” estimates. Points describe the relative complexity of a story.
For example: a 4-point story is probably twice as hard to implement as a 2-point story.
There are several point scales you can use to estimate the work around a user story:
-
Linear (0, 1, 2, 3)
-
Exponential (0, 1, 2, 4, 8)
-
Fibonacci (0, 1, 2, 3, 5, 8)
We use the exponential scale, but it’s up to your team to find out what works best for you.
The Lifecycle of a User Story
| State | Description |
|---|---|
| Not Started | Developers haven’t started work (coding, thinking, whatever) on the story. It’s free for any developer to take. |
| Started | A developer takes ownership of the story and has started architecting, writing tests, and generating code to implement the story. |
| Finished | Code is written and checked into the repository for review by the technical lead and ultimately deployed to the staging server for review by product owner. |
| Delivered | The technical lead has approved the story and deployed it to the staging server for review by the product owner. |
| Accepted | The product owner has reviewed the story and declared that the story was built to his/her expectation. |
| Rejected | The story is not the product owner's expectation and is sent back to the developers. This is not a big deal; rejections happen all the time. The important thing is that the product owner approves all work before it gets deployed to production. |
Accepted stories can then be scheduled to go to production. Developers own the Not Started to Delivered phases whereas the product owner owns the Accept/Reject phase.
Check out our articles on risk management during development and the process of writing code.
Download our ebook to learn more about agile software development and ios app development.
