Waterfall Projects

[Kevin Dow]

Hey, everyone,

I'm new to the group. I'm a veteran of Jira, but I'm currently working with a new company. I'm starting again to set up Jira to handle waterfall projects in a similar way to what I set up a decade ago, and looking for insights on how I can update my processes to sync with new ways of working, facilitated by Jira.

I'm looking forward to some good discussions.

[Anne Saunders]

We're a client-facing dev shop, and most of our clients distrust agile methodologies (they want to know up front what they're planning to pay for!) so we work in a very waterfall style.

I prep our projects in a proprietary application that spits out a CSV that we import into Jira. All of the issues with estimates, assignees, due dates, etc - they're all (ok, mostly) there from day 1. We let project teams create their own sub-tasks to further decompose work on an ad hoc basis, but these sub-tasks pull time from their parent Tasks, so there's no add-on estimation (unless a client agrees to contractual adjustments.)

There's no great, granular burndown or burnup reporting in Jira since we're not using sprints or story points (just Epics, Tasks, and Sub-tasks with discrete hours estimates on the tasks.)

We do like the Time Tracking Report, though. Since we don't use the Jira "Releases" to monitor our software versioning, our operations team has co-opted them to manage the issues worked on under a given client agreement, which gives us a convenient filter for JQL queries and in-project Reports.

[Humashankar VJ]

This is amazing!

[Kalyan Sattaluri]

There are 2 aspects to this discussion. How to set up your Projects vs how to execute them. (I am assuming software projects.)

Some thoughts:

Setting up projects: Obviously many ways to do this, also depends on the kind of projects being worked upon. Lot of small but similar projects under same umbrella vs working on large project. 

Basics - Jira hierarchy can be set up as Epics -> Features -> Stories 

• Epics - Key delivery which is important for stakeholder. Internal Pilot release, MVP, Full rout, Incremental Enhancements, etc
• Features - Sections of work which accomplish  given Epic. Can be broken into business functionality or Technical work but be consistent. (If Technical features, think Mobile Apps screens development, Desktop screens, Middleware API 1, Middleware API 2.. Middleware API n, Other work broken down like Processors, SOR/DB and QA stories, be it End-End or functional or Performance etc.)
• Stories - Division of work on how to achieve a feature. Includes everything needed to deliver a feature's unit of work.

Typically,

• Epics - Driven by stakeholders.
• Features - identified by Dev teams, architect, product managers, SME's etc
• Stories - identified by dev teams.

Use Jira's issue attributes like:

• Features Due Date field to track when its supposed to complete.
• Release Fix versions field at stories to track which functionality is getting developed and merged into branches.
• Priority of Features is based on assignments to team.

Use dashboards for reporting.

Implement Kanban for execution.

Set up working agreement within/between teams on development standards, how to handle cross team communications, how to work bugs.

Of course, you as a project manager will lead all of this and make it happen.

[Sunil Sarathy]

Thanks for the brief overview of the Jira

[Emmanuel.A]

You have come to the right place