In a non-Agile environment how do Business Analysts use Jira for task management?

Question

In a non-agile environment, where we are not using Epics and Stories to drive groups of tasks for the team, does anyone have any advice on how Business Analysts would use JIRA for task management?  There are many tasks in waterfall that BAs have to do before we have requirements.  Those need to be in JIRA as tasks so they can be tracked.  Also, the requirements for waterfall would not cleanly align to tasks for developers with you have functional requirements, system requirements, data requirements, business rules, etc.  So tasks would not be aligned that way.  Any thoughts?

Amy Merritt · Answer

By the way, we realize these are not typical Epics and User Stories.  However, we need to be able to manage and monitor BA activities within projects and across projects.  Some analysts work both on projects that are Agile AND waterfall.  Therefore all their tasks would be in Jira.

Amy Merritt · Answer

We've recently been working to establish an end to end Business Analysis process that we based on the BABOK v3.0.  Having broken that down in the L1, L2 and L3 processes, I'm thinking that the L1 could be entered as Epics in Jira.  Then, the L2 would be entered as User Stories.  From there, the BAs would use the L3 process as a parent task, then break things down in to manageable pieces in a subtask.

Ex:

Epic:  Business Analysis Planning and MonitoringUser Story: Plan stakeholder engagementTask: Perform Stakeholder AnalysisSubtasks:

Identify stakeholder groups

Document stakeholder roles

Document stakeholder A concerns

Document stakeholder B concerns

If we do this in a similar manner across our non-agile projects, then we'd be able to report on things like time it takes on average to complete BA Planning and Monitoring, and then address situations where the time is taking way longer than it should.

Does that make sense?  Thoughts?

Phill Fox · Answer

You have succinctly explained your needs with the different types of tasks and the outputs they produce. From this you could define either a generic BA task or a set defined on the expected outputs, (eg. Functional Requirements, System Requirements, etc..)
If you go with the latter then you should also keep a generic task to cover any thing which does not directly align. For example you might have user interviews for a single specific project phase.