By Splunk January 20, 2008
A few months ago I wrote about our effort to automate and open up product planning by implementing a process around distilling product inputs into requirements using Jira in support of an agile/scrum based development model. I’ve rarely had so much response to a post… dozens of product managers at companies large and small wrote me and commented about their own efforts along the same lines. Many asked for our specs on our Jira customizations.
We were at the beginning of this effort when I wrote that post. In the intervening 3+ months we’ve completed the first round of Jira customizations (thanks to lots of help from Dave Pickering and the team at New Aspects of Software, a fantastic consulting firm specializing in Jira – these guys do what they say they’ll do, when they say they’ll do it, for the amount of money they said they’d charge.) My tireless PM teammates have been embracing the new system and putting in the late nights to coalesce all of the feedback into common problem statements and requirements.
The work all came together for us this past week as we head into the next round of product planning and are reforming our scrums and confirming business priorities – we had a hefty but complete “PRD” that was automatically generated from Jira and represented a comprehensive view of product requirements and concepts. The PM team took about 4 hours to walk through it, confirm our initial priority cut, and then we had an incredibly productive series of sessions with the full business and product leadership to decide which problems to tackle next, how to reform the scrum teams, and what priorities to give each scrum to start with. This was the most ordered and efficient product priority setting exercise I’ve ever been through, because we were dealing with the complete picture.
The PRD report was a custom report built for us by New Aspects. It lets you filter our custom “problem statement” issue type by priority, text matches and other fields; then it prints all problems in reverse priority order. An example of a problem statement would be something like “Splunk doesn’t support the fibberziggy filesystem”, with all ERs asking for fibberziggy filesystem support linked to that problem statement. Each problem shows other linked issues including:
- Inputs: Enhancement requests, Market data points, Call reports (each with details like customer name, deal value, etc.)
- Requirements – with details of status, so we could understand where we were on problems that were already partially addressed by past development
- Features
- Child problem statements (they cascade)
Now the scrum teams are off to do their individual sprint planning and requirements development, with all of that to be captured in Jira as they go. The common “PRD” will stay up to date as they work independently, and best of all, our SEs can see all the way from their individual customer enhancement requests through to up-to-the-minute status of requirements definition and completion. Hardly the case with the old document based PRDs PMs used to create.
Next up we’re going to tackle automating cascading updates based on requirements status updates. For example, if QA validates a completed requirement that Splunk lock test succeeds on the fibberziggy filesystem, we want Jira’s workflow to check that this was the last requirement for the problem “Splunk doesn’t run on fibberziggy filesystems”, close that problem, then check to see if that problem was the last problem for each linked enhancement request, and close those enhancement requests and update our Sugar CRM system via our email integration. We even want interim updates, such as flowing back when we’ve fully scoped requirements for a problem.
We’re also talking to New Aspects about packaging up all our custom Jira reports, workflows and security schemes and giving it to the community, so look here for a post when it’s ready for download.