User story: managing backlogs at Twitter with JIRA user story mapping


Posted by
Rhianne MUIR

June 21, 2016

This is a guest blog by Nick Muldoon, Atlassian and Twitter alumnus and the creator of Easy Agile User Story Maps for JIRA. In this blog, Nick explains how JIRA user story mapping enabled Twitter to better understand customer needs, making it easier to manage backlogs and gain a holistic view of products.

Tweeps in need

I hadn’t been a Tweep (what Twitter employees call themselves) for more than a couple of days before I met a leader of a team who needed help. The team in question needed clarity around:

 

  • Who their customers were
  • The problems their customers faced
  • Possible solutions to those problems, and
  • What a roadmap for solution delivery might look like

 

This team was extremely competent. Their product was in high demand. They were faced with more and more customers coming on board and asking for new features and improvements, and as a result, their backlog was growing fast – REALLY fast!

The team leader was facing the challenge of keeping the team focused on what customers needed, however as the backlog continued to grow, there were more and more distractions. And that’s why we turned to JIRA user story mapping – to help the team understand exactly what their customers needed.

JIRA user story mapping

Story mapping is a technique Agile teams use to create a visual representation of the customer’s experience with a product. In this case, the product comprised of an entire content management system, plus bespoke design for various customers. While common patterns could be identified, each customer had their own needs and milestones.

We started by creating epics in JIRA for all of the large product features and key customers. In this respect, it was an unusual story map – they usually follow the key activities of the customer in chronological order.

 

USM-image1

Epics and user stories

Under each epic, the team dragged and dropped stories, tasks and bugs. This grouping helped the team ascertain the amount of work they had in the backlog for each customer and each of the product areas. It included new features, improvements and maintenance work to pay down technical debt. With stories organised under epics, the team now had a holistic picture.

6

Story point estimation

Each story was estimated using points. Anything with over five points was broken down into smaller tasks to minimise risk. The team didn’t want to risk their workflow, so they kept each item small, ensuring quick feedback when passing through code review. And the smaller the commit, the less risk there is when deploying to production – it was a win-win.

4

Sprint planning

The small stories were essential to the flow of the team, as it worked in weekly sprints. They deployed to production from Monday through to Thursday at 2:30pm. If you were ready and merged with master, you deployed on that day. But if your work wasn’t ready, you’d have to wait until 2:30pm the next day. Again, this team was disciplined and it was reflected in their cadence – the constraint allowed them to move seriously quickly.

Friday was the day to think big, plan for the upcoming week and retrospect. To help them frame the upcoming week, the team would refer back to their story map and drag work from the backlog into an upcoming sprint. This team got to the point where they could have up to eight weeks of work planned in advance.

 

5

Outcomes over output

JIRA user story mapping enabled the team to focus on what was in front of them while keeping an eye to the future of the product. It minimised noise and allowed them to deliver more value to their customers – and do it quickly.

Ultimately the story map enables every Agile team to better understand their customer and solution. It is the best technique to ensure your team understands its customers, can clearly articulate the solution and stay focused on delivery.

Ready to run a story mapping session with your team?