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.
Latest Articles
Comments on all Articles
