| layout | title |
|---|---|
page |
Small steps with visible impact |
Keeping a prioritized backlog of planned work is how we effectively manage an iterative development cycle such that we move toward our goal, incrementally. Simple delivering more frequently, organizing our work into “sprints” is not sufficient. We need to track our forward progress, at regular intervals, reflecting on what we’ve learned, and adjusting our plans to keep moving toward our goal. That forward motion and what we learn needs to be clearly visible to the team and to stakeholders on a regular basis. The best and easiest way to make it visible is to deliver working software at the end of each sprint, and measure the impact on real users through analytics and qualitative research.
Create a single list of all the work that needs to be done on a project. This includes (but is not limited to): features, bugs, design tasks, technical tasks, bureaucratic tasks (ATO, PRA, SORN), research activity, but should be organized into user stories as much as possible. For example: As a user, I can log in with my email address (instead of “implement authentication”) When I visit the site, what I see makes me want to sign up OR When I visit the home page, I can easily understand how to know if I am eligible for services (instead of “design home page”)
Prioritize the backlog according to user needs. Consider how you might do a small portion that could be validated with real users, even if it is a small part of the overall interaction. The backlog is then worked in that priority order, ensuring that the most critical user needs are addressed first.
Each story should convey why the work is needed. if you have too many chores, then it usually means you haven’t thought through the user impact of that work. For example:
instead of “setup server”: As a visitor, I should see a page at http://…
instead of “setup monitoring”: As a developer, if the site goes down I should be notified
As a team, focus on building out a feature at a time, together. It’s important to do this right from the beginning. It can be tempting for team members to individually pursue a variety of different directions, but that makes it much harder to produce a cohesive product.
Working together as a team on a single feature (or group of features) means that at the end of the effort, there is not only something to share with the client but also something concrete to test with users.
Building small is really about identifying things that will have positive, visible impact for the target audience, and building incrementally. To test the usefulness of your solution with real users as early as possible, build a version that’s minimally sufficient to test your assumptions and hypotheses. Eric Ries, author of the Lean Startup, defines a Minimally Viable Product as the smallest possible thing that you can learn from -- not the smallest thing that fully solves the user’s problem. As you learn from people using the service (or part of it), you can improve the solution and iterate in small chunks towards a better looking, more detailed solution. Keep testing your changes.
Stories can (and should) be added to the backlog at any time -- these can be ideas for new features, bugs, or unexpected behavior. The backlog should be groomed regularly during which:
- The backlog is sorted again by priority ensuring new, higher priority items float to the top. Items that have now become less important float to the bottom.
- The description of items in the backlog are written or (re-written) to ensure that they are clear. It’s also important to state expectations around what completion of that item look like.
It’s useful to schedule a regularly occurring backlog refinement meeting. A backlog is a long ordered list which is useful for determining what to work on next. However, because of its format and detail, it makes it hard to see the big picture. Refer to your roadmap to help order the backlog into focused iterations.