Clean up your act: User Stories and Backlog best practices

---

Clean up your act: User Stories and Backlog best practices

As part of my helping organisations with ‘agile transformation’ I quite often see teams struggle to deliver software (obviously). And while there are many reasons for this, again and again do I see teams that write stories that look like something the cat dragged in and forgot, and backlogs that look like a rubbish dump.

At best team’s don’t have the skills, at worst not the motivation to create high quality stories and backlogs.

But make no mistake: I my experience there is a direct relationship between a well articulated backlog and stories and upstream quality of vision and roadmap and downstream input into development and ultimately outcome.

So get on it and clean up your act!

---

Amongst other things, key ingredients into successful project outcome are

• high quality (individual) stories
  leading to predictable feature delivery

• a well structured and managed roadmap and backlog
  leading to delivery of value within wider context of objectives

• the process by which we engineer and manage the above
  allowing us to achieve our goal in an efficient and controlled manner.

I have touched on quality stories in a separate post, and will touch on how we get from an idea to a high quality story and backlog in again another post. For those of the tl;dr persuasion, here is what you need to know (do):

---

Really, all I am saying bellow stems from lean principles (mainly even flows of work in progress and reducing waste) which I assume you have signed-up to, when you decided to ‘go agile’…

• focus what you do
  i.e. either identify stories, or refine them, prioritise, or estimate. Don’t do randomly mix these in one session. Many teams are not focused and oscillate between these activities in a single session (which you can do if you are very mature, not if you in the midst of getting into ‘agile’). Have clear objectives and scope of work for each activity.

• work just-in-time
  Take the subset that is most relevant and work on it, do not work on the entire backlog in one go (except if you want to clean-out your backlog which should not be the norm). In most cases this will be the most-soon up-coming items, but it can also be an area you focus on right now for analysis. Work breadth-first, then depth.

• keep a lean backlog
  a well-managed backlog contains sufficient stories to keep the team busy in the near-term, allows mid-term items to be made ready prior to being required, and provides top-level visibility further into the future. The project backlog should not be a catch-all wishlist for all potential requirements, as this will work against just-in-time principles (see above) and adds noise (see below). Instead maintain separate lists for such indicative items.

• invest the time
  product owners, business analysts! this is arguably the biggest part of your job. Do invest the time it deserves. Higher quality backlogs and stories directly improve your capability to think strategically and deliver

• iterate, reduce uncertainty over time
  work breadth over depth, refine again and again. This is not a one-step process, but an iterative cross-disciplinary collaboration.
  Start with top-level, high-uncertainty detail and estimates and periodically refine, reducing uncertainty and arriving at more and more concrete detail. DSDM Atern, one of the more structured agile approaches summarises this very well.

• high-frequency
  have a periodic cadence of overall roadmapping, a more frequent cadence of planning, prioritisation and estimation, an even more frequent cadence of refinement and an even more frequent (daily?) rhythm of clarification and an even even more frequent (multiple-times-a-day) rhythm of checking and validation of story and features development.
  Again, these are not ‘occasional’ tasks, this s the product owner / business analyst’s bread and butter

• short bursts
   work in short bursts, not in soul-destorying multi-day sessions. The most successful projects I worked on allowed for multiple-times-a-day 15 minute refinement of stories paired with bi-weekly half-hourly overall estimation and roadmapping. Thus, what used to be a tour-de-force, becomes a fairly pleasurable confirmation that we are all on-the-same-page with a bit of an update.

• abolish Scrum-style planning
  Planning should be validation and confirmation, not analysis or other detailed discussion. At planning stage stories need to be well evolved, high quality stories, otherwise we rejected them from planning.
  In highly mature, fully agile teams Scrum-style panning where the team gets first sight of an idea and starts flushing out the details in the planning session, may work. Not so where we work in gated or release-driven agile or where we have an upfront user experience / design phase. Which is, to be honest, the case in most organisations.

• early exposure
  expose all team members as early as possible to vision, scope and stories. I.e. when during planning participants are already aware of the various items to be discussed.

• cross-discipline collaboration
  story and backlog evolution is a collaborative exercise and must involve the do-ers rather than just the ‘ruling’ elite.

• reduce noise
  while collaboration is key, we do not need to involve everyone all the time. The product owner owns the early stages, the business analyst the detailing and the implementation team the dowstream stages of a story, involving other team member’s on-demand only. For instance, the product owner can protect the team from sales&marketing ‘noise’, the business analyst can help team and product owner by ’channeling’ the product owner and thus becoming the de-facto point of contact, knowing where to make decisions, where to ask for minor clarification and where to kick-off major discussions with the team.
  Working just-in-time and maintaining a lean backlog (see above) are other practices that reduce cognitive load.

• proactively lead (in your area)
  as ‘story’ ownership transitions form business (PO) to analysis (BA) to implementation (Dev team) each role needs to take ownership of the stories and pro-actively clarify and challenge as required. In an agile culture it is no longer sufficient to be scribes of clients and servants of requirements.

• reduce waste
  while we may need to spend more time on polishing stories and backlog, ultimately all we do is in the interest of make the flow of work-in-progress as smooth and efficient as possible. So our key goal is to reduce waste in all areas.

• reduce (process) debt
  we are all aware of the concept of code debt these days, how it affects performance and how important it is to pay it off and then prevent it from accruing agin, even at the ‘cost’ of short term reduced performance.
  The same is true for what I want to call ‘process debt’, i.e. impediment accrued due to bad working habits, i.e. sloppy stories or chaotic backlogs.

• ensure high quality stories and backlog
  I have said it above but quality stories and backlogs are key. Product owners need to invest the time to set the right basis, and business analysts need to put the effort in to evolve to the right level of granularity.
  We also need to be strict with our quality rules and enforce our principles (e.g. Definition of Ready / Done) and reject work that is of sub-standard quality rather than ‘dealing with it’ and accruing debt (see above).

• continuously improve
  finally, we need to adopt an attitude of continuous learning and improvement. Where are things working well, where aren’t they? What should we keep doing, what is worth changing (trying out)?

If this was of interest and you are now wondering how to ‘do this’ in practice you may want to refer to this post.