Requirements Management – I’m embarking on a journey to help several teams manage their requirements with their existing systems and tools. This is the first in a series of articles, where the rubber meets the road. I’ll look at both the theory and the realities of what works (and doesn’t) in practice. I hope you’ll come along for the ride.
The Idea That Makes it Tricky To Manage Requirements
OK, so I’m working with a product management team that is working with multiple software development teams. The development teams already have tools and systems in place for tracking work within projects. The development teams are mostly using Atlassian’s JIRA for tracking activity. The teams also have Atlassian’s Confluence wiki for capturing “other stuff.”
The development team has a good working process for managing their delivery activities within the “JIRA world.” From the top down view, you find a project (in JIRA) that represents what will be delivered in a particular release. Within that project, you see the issues (or user stories or requirements) and associated tasks that were previously scheduled for that release.
This is pretty effective for getting a handle on what’s happening. Where it falls short is in getting a comprehensive understanding of why it is happening. And that’s the view product managers need.
Why something needs to happen is completely different from when something needs to happen. That’s what makes this tricky. Consider the following analogy.
You’re driving across the country from Los Angeles (LA) to Manhattan (NYC). Your goal is to get to Manhattan. Your product manager creates a map, breaking down, roughly, how you will get from LA to NYC. Your product manager is riding shotgun in the car, and he’s responsible for telling the driver where to go. Your developer is driving the car, and is responsible for getting the car wherever the product manager tells him. They share the responsibility for getting to NYC – neither of them can do it alone.
They climb in the car, and start driving. When the developer has a question about a particular way to go (which highway to take, etc), they communicate. Together, they make great progress. After a while, the gas tank is empty, and they stop to fill up. This is a logical break in the drive, and they stretch their legs, get some dinner, whatever. With a full tank of gas, they get back in the car and start driving again.
Managing requirements inside the context of a release (in JIRA) is like saying every time you stop for gas (finish a release), you should create a new map. The goal (destination) is independent of the release cycles (gas tanks). The requirements should live outside the release. However, the turn-by-turn information is useful inside the release. The product manager needs to provide the next level of detail (first, get to Las Vegas, then stay at the Westin,…) for each “tank of gas” – after which, that information is not very valuable, and can be discarded. But the goal (reach NYC) stays alive.
A process and system for managing requirements should not force product managers to recreate documentation for each release. Your stakeholder (perhaps you’re delivering a donated kidney to a hospital) needs to know when you’re going to deliver the kidney. The last place they should have to look for that information is within the context of the current project.
This is what makes it tricky.
JIRA and Confluence
This is not a series of articles around picking the best requirements management solution available today. These articles will cover the exploration of using JIRA and Confluence to make (1) the product management teams more effective, and (2) the combined product delivery teams (management, marketing, development, quality) more effective. We’re faced with a real-world constraint that we will use these tools that are already in place.
Product Management Goals
There are a series of goals that we have, that will inspire our implementation choices (of how we use Confluence and JIRA), and ultimately provide the measure of our success.
- We will not remove or regress things that are working today. The implementation teams (development and test) are delivering products, and using JIRA to track issues and tasks. Whatever we do must not break this current world.
- As product managers, we are continually investing in, and updating, our understanding of our markets. We need a solution that allows us to record that information in a way that we can (a) share with each other effectively, (b) remember what we need to remember, (c) make changes as needed so that the view we have documented is always reflected of the understanding we have “in our heads.”
- As a delivery team, we need to connect the two worlds (“what am I doing” and “why are you doing it”), so that the product managers can let the implementation team know what to do next (and what they will eventually be working on).
- As a company, we need to set and manage expectations – internally to stakeholders and externally to customers and partners.
These are the problems we’ll be tackling.
This series of articles will capture elements of implementation choices, why we made them, and the rationale “behind the whys.”
I hope you’ll come along for the ride.
I look forward to this journey. We use Jira and Confluence, and while they seem to be good tools for managing the existing and past development iterations, they feel like cumbersome tools for managing a backlog that is fairly fluid.
I have heard of a Jira add on that is supposed to be very helpful (Will have to dig up the name) for managing a fluid backlog, but our company pretty much goes with stock.
Currently I use a cumbersome, but manageable excel sheet for my backlog, both to create the stories, and to prioritize, then when we go through the planning process, we enter the stories, and acceptance tests into Jira. Workable for a team where we are all co-located, but it really falls down for my team in India.
Thanks, Geoff, for joining in here!
Please let us know when you find the name of the plugin. Right now, we’re kicking the tires on Greenhopper.
Yeah, I’ve lived in excel world a lot too. Historically, I’ve used Evernote when originally capturing interview notes, and ad hoc market data (with the clipper extension in Chrome, or with old-fashioned cut n paste). Not because Evernote is particularly well suited to it, but because I use it all the time for other note-taking, and because it syncs with my phone – for “eureka moments” when I’m away from my laptop, or just reviewing stuff while standing in a line or walking my dog.
I’ve even managed delivery in an excel spreadsheet that let me track stories, tasks, estimates, and delivery by release. Worked great, with a co-located team (and no warroom). I’ve also had good success with sticky-notes and walls full of information – also with a co-located team, and available/dedicated space. This got a little tedious, over the course of a year, when my combo office/warroom was moved twice!
My approach in this exploration is “get functional first” followed by “get less cumbersome second.” :)
Scott,
Greenhopper is the add on that the team sung the praises about. However, it was a development team’s perspective, not a PM or PO perspective.
The problem is how to get a tool that works for both halves. I am willing to undertake pain if it smooths the path of dev. But, it should be noted, that there is a limit, and plain Jira is one of those limits.
Geoff
Scott, I agree with your desire to try and tie requirements and deliverables and the big picture. This was something that I had looked at about 3 years ago. You may want to check out Application Lifecycle Management term for some ideas.
One other point/question is it is nice to know when you start your trip in LA that you want to get to NYC. In the hypothetical realm you are omniscient about the full details of your project. Real life tends to not be so clear unless you work for NASA. Maybe you lost all your money in Las Vegas and need to return to LA or you might run into a tornado in the mid-west that forces you to get some repairs or circumnavigate the area. What if your kidney patient is in Miami because their is a specialist there, etc.
The way I read your post, the periodicity you are updating your plans and managing them in that context. LA >> NYC sounds like a 3 year roadmap. Generally, anything beyond 9 – 12 months is pure speculation, IMO. Atlassian tools forcing the team to review and plan at the gas tank level doesn’t sound that far out of whack. Based on how the last gas tank went, using the metrics of time, MPG, distance traveled, etc. what are you going to do differently with the next tank? Where are you going with this resource (tank of gas)? When will you arrive at your next destination (aka product release) or ETA? At this level you get granular without being a backseat driver.
Your forward progress is never taken away. How your arrived at where you are at is available in the archives in the event anyone wants to review, but it shouldn’t hinder future forward progress. Also by reviewing frequently, you don’t have to plan for and anticipate tire or oil changes or any of the other larger deviations listed earlier.
Can you use alternatives to keep track of your bigger picture goal such as sharepoint, web pages, hierarchical wiki elements, powerpoint updates, word documents etc. These would offer flexibility and foster communication without overly constraining the team.
Of course, I am working with limited information so I will wait for the story to unfold in the event I am off track.
Hey Larry, thanks – will definitely check out ALM stuff.
Great point about the destination changing :).
In sticking with the analogy, imagine we just arrived in Dallas, and the plan for the next “release” is to drive towards Shreveport, because our long term roadmap has us crossing the Mississippi River on I20.
When I hear on the radio that the bridge on I20 was just washed out in a flood, I need to rethink the roadmap, and plan on routing through Little Rock so we can cross the Mississippi on I40.
The context (goal of reaching NYC, via I40 and a bunch of other routes) has changed – which is useful information for the driver to know, because it impacts the current release. It is also useful information to have tomorrow (when we drive to Montgomery, instead of Memphis). That’s why it kinda breaks to put the information (use I20) inside the gas-tank level plans – because I have to keep doing that over and over.
As I write more, our emergent design will emerge :). But yes – the top-down view is being captured in the wiki, the release-to-release view is being captured in JIRA. Focusing right now on connecting the two views with (a) minimal overhead, and (b) good support for the situations where someone starts reading in one view, and wants to continue reading in the other.
A couple scenarios:
I care about what we’re doing for vertical X. I’ll want to review both the plan (and its rationale) and our execution against it.
I care about what we’re doing in release Y. I read a user story, and the acceptance criteria. I know that changing one of those acceptance criteria makes implementation a lot easier – I want to understand the context that drove the criteria, so I will read up on the big picture.
Also – an important note: This documentation is to help us “remember what we already talked about.” Conversation is first. Capturing it so that we remember efficiently (with accuracy and minimal overhead) is where the tools can help.
Thanks again!
A really interesting post as well as follow up comments.
I like the driving analogy. However, I don’t totally agree with the statement, “…after which, that information is not very valuable, and can be discarded.”
Imagine you’re driving along, and suddenly you realize you’ve lost your cellphone / wallet / mattress off the top of the car / mind. You’ll need to be able to retrace your tracks to try to find it. Just like in software, if something is broken in this version, you may need to go back to see where changes were made and what damage it might have caused, etc. Just a thought.
Thanks, Dina!
You’re right, and I wish I had caught that when I was creating the analogy.
I’ve worked with teams on long-lived projects, and often something was “getting in the way” but everyone was afraid to remove / touch / fix it, because they had no idea why it was there, or if anyone were using it. Because they didn’t keep track of why it was put there in the first place.
I think this is where the metaphor falls apart. Thanks for catching it – future readers will definitely benefit!