nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What's your company's work flow for inputing SW Requirements?

David Dube

Before people mention Green Hopper (which we use), there is a slight nuance...

Background:

We have an internally installed instance of Confluence, and are using On-Demand versions of Jira and Green Hopper.

Our business teams have a myriad of ways of ways for tracking requirements... some still use excel, others list in confluence and don't input into Jira, others enter into Jira, tag as an enhancement and as a business req, and then manage in Green Hopper.

We briefly looked at Wikidsmart, but ruled that out as we're using on-demand versions of Jira and GreenHopper.

I'm bet there are a number of people who would like to share their "best practices" out there... any suggestions?

Regards,

Dave

Accepted answers

BillA

There are probably infinite ways to do agile software requirments. On the Confluence dev team we use Confluence and Greenhopper extensively for planning and tracking requirmenets. When we're working on a new feature area, we'll create a requirements document inside Confluence using the Product Requirements Blueprint. This allows the PM to describe more intangible things like feature goals, strategic fit, UX thoughts, competitor examples, etc before they dive into the indiviual requirements and stories.

The requirements document goes through an informal review process where a PM, developer, design and QA engineer will review the document and give comments. Once everyone's had a chance to review and comment, we change the document status to "reviewed" and copy the stories into Greenhopper where we can estimate them and put them into weekly sprints (most teams use scrum). We also link the GH stories back to the individual stories in the Confluence requirements document using the JIRA macro so that anyone looking at the document can see the status of each story and click into the JIRA ticket if necessary. We also link the document to the Epic for traceability. (A requirements document typically maps directly to a Greenhopper epic.)

Then we plan our sprints and do our estimation. At the beginning of the sprint, we create a Confluence page for each sprint planning meeting so that we can track things like sprint goals, team leave, etc. At the end of the sprint we'll hold a retrospective and record the results in a Confluence page so that we can refer back to the conclusisions and recommendations and continually learn as a team.

Once all the stories on the requirements doc are implemented, we change the requirements doc status to "done." In the Requirments Blueprint Collector page we can then see a list of all the requirements and where they are in the review/implementation process.

My colleague also wrote a post about this very thing at http://blogs.atlassian.com/2013/07/agile-requirements-documentation/ which also has some great ideas and dicussion on this topic.

All comments

Justin Alex Paramanandan

First off, the combination of JIRA with GreenHopper and Confluence would benefit greatly in your software requirements gathering (since all of this can be integrated via Application Links). However, there is but one difficulty that you will face; which is the application links between JIRA OnDemand and your in-house Confluence could not be made due to the restricted platform of the OnDemand instance to allow external connectivity (see this Answers thread for more information on this regard).

This is my suggestion for applying the concept of software requirements gathering; it can be made with the above mentioned products if you have a practise like this:

Whenever you have a new requirement, make sure that it is created in JIRA first.
Create filters that is specific to a particular scope. This can include:
1. specific product,
2. specific issue type (Bugs, New Features, Task etc),
3. specific tagged options (business requirement, enhancement etc)
Create an application link that links JIRA and Confluence (remember, this would only work when you have an in-house JIRA instance, or added Confluence OnDemand in addition to your OnDemand products [application links would already be created when this is such]).
I believe you already have a space in your Confluence to cater for specific products. In each of this space, create a JIRA Issue Macroto showcase the issues that pertains to the product in sections. For example:
1. If your have product A, have specific pages for:
  1. Bugs
  2. Features and Enhancements
  3. Business Requirements
2. In every of this page, input the JIRA Issues Macro and use a filter specfic to the section:
  1. For the Bugs page, show all issues from product A of issue type Bug.
  2. For the Features and Enhancements page, show all issues from product A of issue type New Feature or have the tag enhancement.
Then, manage these issues in GreenHopper.

I feel that this is the best practise that I can imagine being an easier way to track requirements. If there's anything I left out, do add more information and we can see how we can proceed from here.

Woody Arnold

It may help to know more about your environment and process. How many developers do you have? Are they co-located or offshore? Are you using Scrum or some sort of hybrid? Your question seems to imply you feel you need some sort of requirements document. Is this accurate? Why do you feel this way or why does your company have this as part of their process?

At my last two companies (current and prior), we abandoned traditional requirements documents when we adopted Scrum. Both companies had similar environments -- "small companies" -- 30+ developers, local and offshore, 3-5 Product Owners, 1-2 Scrum Masters. Separate business stakeholders that made requests of the engineering teams. In general a cooperative spirit where the business would request a "project" and the POs would flush out the details. There were review sessions but no "sign-off". Stakeholders would participate in Sprint reviews.

The stakeholder's requests would generally become Epics in Jira. The details would be flushed out as Stories by the PO. We use the Scrumboard to tie stories to Epics. Stories can be reviewed with the stakeholder online via Jira or exported to Excel or Word for review. (However, we made it clear that Jira was the "source of record".) Occasionally we miss having the holistic view a document and pictures provide, but again this can largely be met by exporting into Excel, and referring to UI wireframes or mockups. At least this has worked for the environments I've been in.

BillA

My colleague also wrote a post about this very thing at http://blogs.atlassian.com/2013/07/agile-requirements-documentation/ which also has some great ideas and dicussion on this topic.

David Dube

Cisco in general employs a mix of waterfall, agile, and hybrid design methodologies. It depends on the organization, type of development (end product), and historical/familiarity with various methodologies.

In order to attempt some level of integration between our On-Demand Jira instance and our internal Confluence instance is that we set up a specific user account in Jira, and leverage those credentials to pull content onto our confluence pages. Great for viewing issues... could be better for more interactive manipulation within Confluence (IMHO).

David Dube

Thanks for the blog link! It's funny your colleague mentioning the dearth of PRDs. It's probably more applicable at larger companies, but I personally have evolved my PRDs to paint a bigger picture of the rapidly evolving competitive and industry landscape. I've found the developers and testers appreciate having someone keep a finger on the pulse of the industry in an easily digestible doc. I'll also insert customer quotes around key requirements.

When I get to the requirements section, I'm also creating corresponding jira issues, and then referencing (hyperlinking) those jira tockets within the doc. For the most part, our dev team works 100% out of Jira.

So why the PRD? It ends up being more of a customer validation/justification document (for me anyway) - helps move the resource allocation (we leverage shared development resources - capacity based model) process along.

Ultimately, one adapts to the confines of the organization. Just trying to find ways we can improve the flow... one step at a time.

David Dube

It depends with the team, but I personally do 1 - 4 as part of my daily flow (leveraging jiraissues macro to import Jira content into our confluence instance). As part of our requirements doc writing process, I do create the corresponding Jira issues, then reference the specific jira issue #'s along side the requirement so people can reference later on.

We'll update the Jira issue as the user story, ux, etc details evolve throughout the development process.

The big question at this point is whether to incorporate deeper ties using Greenhoper or some other 3rd party utility.

Ira Leventhal

Justin, we really like the process you described and are looking to adopt it. Can you clarify how you structure your requirements in JIRA? Do requirements belong directly to specific projects or do you have a separate Requirements project that contains all requirements, then use some other method, such as labels, for mapping requirements to projects?

Justin Alex Paramanandan

Actually, the idea of placing requirements, development tasks and testing tasks in one project would be the ideal outcome. On my previous job, we manage our sprints in the order of:

Requirements / Analysis > Development > Code Review > Testing > Documentation > Code Merge

The structure of this in the context of a JIRA issue would be:

- Bug/Enhancement/New Feature
|- Requirements / Analysis (Subtask)
|- Development (Subtask)
|- Code Review (Subtask)
|- Testing (Subtask)
|- Documentation (Subtask)
|- Merge to Repository (Subtask)

This way, we ensure that we track estimates accordingly and we have a breakdown on where effort is spent the most.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

jira-software