Suggest the best Jira practice for the mentioned scenario in description?

[Prakhar Vedsa]

1. When the product team shares any functional work with the development team then we want to track how much time a particular platform(Android, iOS, Web) spent on a particular activity such as actual development, discussions, research, modifications, and bug fixing of a given assigned story? 
Also In the development work, how many hours we spent on testing or in a code review?

2. Let's say we have done the development of a particular story in Sprint-1, but now the modification/alteration is needed & we are on sprint-2 then how we should manage this?

3. If Story is not completed but there are changes in the requirement/scope. If the dev team has completed work & given it to QA but then QA gave it again to the dev for rework. How to manage this?

4. Suggest the Columns and statuses that would be useful in our case or globally used for stories?
(Currently, we are using: Todo, In Progress, QA dev, QA Staging, QA Prod, and Deployed)

[Mark Segall]

HI @Prakhar Vedsa 

1. When the product team shares any functional work with the development team then we want to track how much time a particular platform(Android, iOS, Web) spent on a particular activity such as actual development, discussions, research, modifications, and bug fixing of a given assigned story? 

If you need to track time, the best way to handle it is by enforcing time tracking.  It frustrates the team, but frustrates them less than trying to do something like tying story points to time.

2. Let's say we have done the development of a particular story in Sprint-1, but now the modification/alteration is needed & we are on sprint-2 then how we should manage this?

Stories should be broken down to their smallest component to allow them to be worked from start to finish in the same sprint.  Stories that span multiple sprints are typically not broken down enough.  They should always have well vetted Acceptance Criteria to minimize modifications/alterations.  However, misunderstandings happen.  In this case, the story should still be closed and then a second story should be created so that the initial work that went into the story is not lost (you can link the second story to the first for traceability)

3. If Story is not completed but there are changes in the requirement/scope. If the dev team has completed work & given it to QA but then QA gave it again to the dev for rework. How to manage this?

Similar to above, there should be clear Acceptance Criteria captured prior to bringing the issue into sprint.  Dev and QA should be part of the sprint planning so there is an aligned understanding on the story.  If the issue is being worked on mid-sprint, it's best to flag it to signify it is blocked and even consider removing from sprint for further refinement.

4. Suggest the Columns and statuses that would be useful in our case or globally used for stories?

I've found the simpler the workflow the better.  The first question I ask myself about statuses is whether I"m contributing to or hindering a culture where all issues are getting resolved each sprint.  I've found that the more statuses involved, the more likely that the team has too many balls in the air at any given time... Basically, is each team member working independently of one another or are they actually collaborating with a common goal of doing whatever it takes to get the current story to the finish line?  A team that is functioning at peak efficiency is focused on the sprint and not individual assignments.

[Emre Toptancı _OBSS_]

Hello @Prakhar Vedsa ,

Mark's answer pretty much covers the important points but I would like to make some additions.

1- When working with sprints, the team concentrates on the sprint backlog and does whatever is needed to complete the sprint backlog. Many things run in parallel in such high-velocity environments. Lines between those stages become very blurred. I suggest you to keep your workflow simple and do not try to measure things like actual development, discussions, research, modifications, and bug fixing. You probably won't be getting trustworthy results even if you try to measure these.

2- A story must be small enough to be completed in a sprint. If a modification request comes for something that was completed in an earlier sprint, that is a different story that needs to be estimated and planned separately.

3- All the development and QA stages must be part of your Definition-of-Done. There is no such thing as "partially completed". If a story is not completely Done in a sprint, that story (or whatever work is left of that story) must be moved back to the product log (to be evaluated, analyzed, estimated, and planned again)

4- As I said earlier, I suggest you keep the workflow as simple as possible and let the actual work dictate what statuses are needed. 

Having said all these, if you need to measure the time in your workflow stages, you will need to use a marketplace app for this. Our team at OBSS built Timepiece - Time in Status for Jira for this exact need. It is available for Jira Server, Cloud, and Data Center.  

Time in Status mainly allows you to see how much time each issue spent on each status and on each assignee. 

       

The app has Consolidated Columns feature. This feature allows you to combine the duration for multiple statuses into a single column and exclude unwanted ones. It is the most flexible way to get any measurement you might want. Measurements like Issue Age, Cycle Time, Lead Time, Resolution Time etc.

For all numeric report types, you can calculate averages and sums of those durations grouped by the issue fields you select. For example total in-progress time per customer (organization) or average resolution time per sprint, week, month, issuetype, request type, etc. The ability to group by parts of dates (year, month, week, day, hour) or sprints is particularly useful here since it allows you to compare different time periods or see the trend.

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well. It supports both Company Managed and Team Managed projects.

Time in Status reports can be accessed through its own reporting page, dashboard gadgets, and issue view screen tabs. All these options can provide both calculated data tables and charts.

And the app has a REST API so you can get the reports from Jira UI or via REST.

  

Using Time in Status you can:

• See how much time each issue spent on each status, assignee, user group and also see dates of status transitions.
• Calculate averages and sums of those durations grouped by issue fields you select. (For example, see average InProgress time per project and per issue type.)
• Export your data as XLS, XLSX, or CSV.
• Access data via REST API. (for integrations)
• Visualize data with various chart types.
• See Time in Status reports on Jira Dashboard gadgets

Timepiece - Time in Status for Jira

EmreT

[Adriano Mendes [HeroCoders]]

Hi @Prakhar Vedsa 

My name is Adriano and I'm a Support Analyst at HeroCoders.

We have two plugins that can help you.

Regarding your first question, we suggest using the Clockwork plugin for time tracking. You can use the manual worklog, which means that each analyst/developer can add a worklog to an issue manually. Or you can use automatic time tracking; every time that an issue is on active status, the timer will start.

You can find more information about the plugin here. Also, I'm sharing our documentation so you can read it and decide if the plugin will fit you.

Regarding the last three questions, we suggest using the Issue Checklist plugin. With it, you can create a checklist in your issue which will contain items (tasks) related to a specific Story (or a different issue type). You can also create custom statuses for the checklist. For example, you can leave the issue "In Progress" but the checklist items will have statuses like "QA dev", "QA prod", "Deployed", etc.

In this link, you can find more information about our plugin and if you seek more information about it, you can check our documentation.

If you would like more information and assistance on how to use our plugins, you can raise a ticket with our Support Desk, we will be happy to help you.

Thanks and Regards,

Adriano