Planning/Reporting with BAU style workload

Steve Stevens January 24, 2019

My team uses Epics to collect Stories/Issues under Key Deliverable features which are goal orientated. ie, Deliver Product X to production.

But we also have to manage Business As Usual (BAU) requests, such as creating new SFTP accounts.

We want to start reporting more clearly the progress of an Epic and its Stories and have setup a "Releases" page to highlight the progress on these items.

However, we are unsure how to manage the BAU tasks as the "epic" is continuous.

It doesn't make sense for us to "COMPLETE" the BAU epic, as requests will appear adhoc, so it is never truly closed.

It also doesn't make much sense to leave the Epic "IN PROGRESS" because all the known tasks are likely complete.

 

Does anyone have any suggestions for this type of work so that we maintain visibility to the business without misrepresenting the work?

2 answers

0 votes
Caoimhe Kennedy December 15, 2020

Our team has BAU EPIC for each quarter, that way the EPIC is not continuous and we can easily see what was done in each quarter.

0 votes
Lime Trees January 24, 2019

Hi,

There's a lot of possibilities in Jira - it all depends how you would like to see these BAU tasks from your perspective.

You can create whole new project, especially for all BAU tasks.

You can add special user story for each Epic representing particular goal and then collect sub-tasks with BAU activities.

You can also make one user story for the project which will contain all these BAU things.

From our point of view and experience in project management and reporting, all of these solutions have its pros and cons - it would help if you could share some more information - are BAU tasks connected with particular product/goal? Are they repeatable? etc.

Regards,

Lime Trees Support Team

More about us

Steve Stevens January 25, 2019

Hi, 

Thanks for the speedy response!

A prime example of a BAU task would be creation of new SFTP accounts and access to those accounts.

We manage an SFTP server for the Integration Teams. We separate accounts by "business" (eg, _atlassian_prod, _argos_prod, etc) and we grant access to them based on client project (eg, cli_1 -> _argos_prod, cli_2 -> _argos_prod). We may receive multiple requests in a week for new accounts or access to those accounts, and sometimes we don't receive a request for months.

Other BAU's include, creation of new RDS instances (+ access), creation of S3 buckets, whitelisting IPs for 3rd party access.

Each account request is the same as the last but with a variable name/user/account. I've also created templates for all these BAUs so new requests are in the same form. The "task" itself is not repeatable as it is not identical, but the actions are almost always the same.

Currently, these BAU tasks are marked with "type" BAU, but not grouped under an epic as they are not meeting a larger feature goal. However, management would like to be able to see progress.

Someone in our team suggested we create an Epic that never closes, and raise a story per week which we add all actions to and close at the end of the week. If no actions appear, close at end of week. This would show "progress" but for something that will continue indefinitely it seems like a maintenance overhead that doesn't really provide a good view of effort.

Cheers,

Steve

Lime Trees January 25, 2019

Hi,

It seems that both solutions you have in mind are correct and make sense.

If we can suggest - tasks with BAU type, placed in project, can be easily grouped under specific Epic, if in some point it will be helpful to see which BAU activities are connected with given feature.

If you generate separate Epic with BAU tasks per week, you won't be able to link them with specific goals.

Cheers,

Lime Trees Support Team

More about us

Like Daniel Barrett likes this
Daniel Barrett January 14, 2021

I agree with this. In order to track efforts and tie them back to valuable products, it's important to map them to features.

If BAU work can be/is planned it's best in my opinion to include it in the backlog, and work on them in sprints along with feature development.

If it's unplanned fire fighting, or fast turn around request type of work, it works best separated out from sprints. Kanban would probably be more effective for this.

Like Sjaa likes this

Suggest an answer

Log in or Sign up to answer