How to work with Time estimation along with QA assignments and Dev assigments

[Aviad Hadida]

Hi. First of all i am not a newbie in Jira.. But i couldn't find anything that can give me this simple requirement that we need in order to have simple workflow.

Our current workflow is that:

Open -> Dev in progress -> Dev done - >Pending QA -> QA in Progress -> QA Done

We need really basic thing. We want to estimate our tasks and plan the sprints based on that.
I went over endlessly examples and even tried to use the Jira Permium, Epics, Stroys and subtasks but nothing gives the required result.

Anyone can help here? Give me a link to real life examples?
If i use subtasks it is not very easy to sum the effort and this is really hard to manage.
For example:
Story: Login
Subtask: Server side
Subtask: Client side
Subtask: QA

Now the board need to be updated on the parent along with the subtasks all the time.. Hard to maintain.


Please HELP!!

[Gustavo Félix]

Hi @Aviad Hadida 
What do you mean in this point ?
"Now the board need to be updated on the parent along with the subtasks all the time.. Hard to maintain."

I have a project where I use subtasks with time estimate and another project with story points estimate. But I'm using customFields to save this estimates. My burndown chart is based on this fields.

On another project I work with a Dev Story and a QA Story. Each one passes through todo - in progress -done .

I like more the second approach, but I guess depends on the number of stories you are working with, and what do you want to see on your board.

Hope this helps you.

[Aviad Hadida]

There is basically 2 major flows:

1. Big tasks - Create an Epic and stories.. After that each story is divided into sub-tasks per skill(Front end, Back end, QA).  and estimate the sub-tasks
2. Bugs / Small issues / Tasks - Divide into sub-tasks if needed.

So the problem here:
Who is assigned to the Epic? Who is assigned to the story? On the board lets assume that developer works on a sub-task.. Someone needs to update the Epic along with the Sub tasks and the same for the story.
And how it will look on the reports? How to log time? 
Lots of questions that it seems not to fit most use cases that i know.. 

Regarding the story points.. I must say i like it better than time estimation. But story point exist only on stories.. What about bugs?

And eventually story points needs to be converted to time for the business needs. Eventually the business works in timeline.

So it is not clear what is the correct path.. I would expect Jira to publish some real life use cases and examples

[Gustavo Félix]

I dont think there is a correct path, maybe more like best practices, but you should define your process and adapt jira based on your process.

Answering some of your questions based on my experience:
The epic could be assigned to someone on the team that has experience on that "epic". Doesnt matter if he is participating in an story or not. 

If you have bugs or another tasks , that's a different issue type. In that case, your available time for a developer should be less % assigned to a sprint, because he has assigned time for bugs. 

Again, that's on my experience , because I've also seen for every bug they create a story
with no story points. 

Someone needs to update the Epic along with the Sub tasks and the same for the story... in my opinion , that should be automated. If your epic has 10 stories and their status is done, it should be shour decision to put on Done the epic. If a story has 3 subtasks and the status is done, automatically your story should be on Done. 

That's on the workflow process. About the worked time on each subtask, you could sum all the subtasks and put the value on a story field. That way, the total worked time would be on each story.

I hope some of this ideas/practices helps you in any way. 

[Mehmet A _Bloompeak_]

Hi @Aviad Hadida ,

We have a similar workflow. It is not a direct answer to your question but it can give you an idea. Below is how we do it.

ReadyForDevelopment -> InDevelopment -> ReadyForTesting -> InTesting -> AcceptedInTesting

We estimate the complexity of the story as story points. The estimate includes both Dev and QA work. And we do not create subtasks inside the story. This kind of estimation gives team the message that we are a single team and there is no hard separation between devs and qas. Also, we emphasize to the team that we are team of T-shaped profiles, who has one major expertise but can work on one another's work if needed. E.g developer can  work on qa tasks if there is overload on the ReadyForTesting column of the board.

[Aviad Hadida]

Thanks for you response.. Indeed this is an option.
The case i describe is so common.. And it looks weird that every company create different workaround.

I wonder if Jira expert has some real life solution of guidelines how to implement to real development process