How does one manage scope in JIRA?

Question

I work in a software development company. We develop with Fixed Price contracts, thus there's a lot of BDUF (Big design up front). During the initial/planning phase, we create very big monolithic technical scope documents in MSWord and get approval/signature from the customer on it. Then, during development, we refer to these documents: e.g.: "as per page XX",or "as per section XX", in our work in JIRA tickets. Change requests cause a new version of the specification to be re-created from the MSWord and the modified section or appendix at the end is re-signed. Our customers always need to sign something, they prefer it this way.

I wonder if you can help with the following please:

• Is there a way to type the scope in a more granular manner directly in JIRA (e.g.: one functionality per JIRA) and automatically generate a big document to be "signed"?
• Would it be possible somehow to track modifications in the JIRA after the signed version was done?
• Would you use a different tool to type these specifications? E.g.: a tool that somehow integrates into JIRA and you have the scope in there already in a granular manner?

This would force the writers to write the scope in more concise and self-contained manners (and all the scope would be in JIRA facilitating communication). Please note that typing the scope in MSWord and then moving it into JIRA is also an option, but a lot of re-work (~100 pages of it), thus I am looking for a solution where I need to write this only once.

Any help is appreciated.

Thanks!

Answer 1

Sounds that you are looking for a Requirement Management Tool like Doors. This would be an off-topic question and you might find better answers in Software Recommendation StackExchange.

Nevertheless, you are asking a project related question: How to deal with scope and scope changes.

The general mechanism regarding scope and scope related changes are Baselines and Change Requests.

Baselines freeze a specific set of e.g. requirements e.g. at the contract phase. Changes during development can be tracked using Change Requests. You usually pull a new Baseline at a milestone, e.g. PDR or CDR. During Change Control Board meetings you decide how to deal with the different CRs and if you should involve the customer somehow.

You can use any tooling for this purpose but you might find it helpful being assisted in pulling baselines and tracking changes. Jira might be nice to track progress while plain text exports (xml, csv) as Baselines combined with git might be a tool satisfying this needs. Requirements are often build in a hierarchical manner. I think Jira offers 3 hierarchy level (e.g. Epic, Story, Task). I don't think this is enough.

There are multiple tools specialized on requirements management. They usually support everything described above. Just google a bit.

Answer 2

The basics of how to organize a project like this in Jira are well documented on well, Jira's Confluence site, and granularity issues are directly addressed in Atlassian's Delivery Vehicle's page.

A very brief distilled answer is that:

• Create a User Story to document the tiniest unit of releasable feature (something that the customer can review, test and validate)
• Group user stories into Epics (Related small units of features)
• Optionally, if it makes sense to you, you can group Epics into "Features" or higher level units that make sense for your project.

Ultimately, you will have to define whether each "signoff" event that happens with your customer is at the level of a user story, epic, or something else. That determination may be made on the basis of how informal or expensive a "signoff" is - more expensive and formal the signoff process is, the higher grouping you would want to use.