2

When we have features, we usually break them down to tasks that take about 1-2 days. Usually our dev tasks are not ready for QA as soon as a developer finishes developing them, but only after the whole feature is ready. That means that a few tasks (and probably a few features) would already be finished by the time QA will start testing the version. We usually try to decide ahead what bugs/features the next version for QA will have.

So, When QA open bugs they won't be directly correlated to a specific dev task but more to the feature as a whole. Moreover, our QA usually test features based on their own test plan, which is not directly connected to our development tasks on JIRA.

One possible solution for this issue, is to have all tasks belonging to a specific feature, opened as subtasks under that feature. When each subtask is finished, mark it as resolved. When QA starts testing the feature, they will open bugs under that main feature (I can link the bugs to the main feature I guess), which will go back to the 'In development' stage, till all bugs opened on it are resolved.

Another option, is to have all subtasks of the main feature as resolved, but have the main feature stays in an "Waiting for QA" column. I will move it to done only once all bugs on it are fixed.

Which solution is better ? Do you see any downsides or ways to improve that process ?

My goal is to be able to confidently say how many tasks we manage as a team to finish in week/month time(or what is the cycle time of an issue) so I can more or less know once we break features into tasks, how long it will take the team to ship them. As far as I'm concerned, finished also means verified by QA. I want to find the best way to handle our current process.

Improve this question
1
  • This sounds very much like "ScrumFall".
    – Muhammad
    Aug 3, 2017 at 9:59

1 Answer 1

Reset to default
1

I would work on making the stories independently testable by working together with the testing folks. Narrow the testing scope so that you could attach bugs to stories and not to the whole feature.

If you cannot do that or maybe save it for future, out of your solutions I like the second one best. Having the feature in "Waiting for QA" signals better that it is not actually done yet! Also that way you could have your Stories be completed and track the completion of the feature by the stories that are completed. As you're using JIRA you can also use Epics as a place to store information about the whole feature if you want to.

In our team we have epics that contain User Stories that have sub-tasks for technical documentation and planning. Bugs are linked to the User Story and also to the Epic.

Improve this answer
6
  • 1. Do you release a version to QA once a user story is done or once the entire feature is ready ? if once the user story is done, what do you do when a user story itself alone is not testable ?
    – Idan
    Aug 4, 2017 at 9:41
  • 2. What happens once QA find bugs in a user story ? it goes from 'waiting for QA' to 'In Development' or only the bug is 'In Development' and the user story stays in 'Waiting for QA' ? What happens to the Epic ? 3. How do you measure the team velocity ? the cycle time of a user story ? feature ? What do you do when there are no QA resources available ?
    – Idan
    Aug 4, 2017 at 9:48
  • 1. We make a new QA release every time a new story enters QA. We aim for independently testable stories - otherwise they really don't fit our definition of a story. In rare cases that these happen we make a note of it to the JIRA ticket and link them with blocked by/blocks. 2. We let it stay in QA and fix the bug. The bug is usually a sub-task of the story since in our process bugs can only be found from production. So the story is 'In QA' for as long it takes to fix all the bugs. 3. We use story cycle time. We have dedicated testers in our team that work only for us.
    – vvmann
    Aug 5, 2017 at 8:57
  • I see. Do you have an automated way of creating a build every time a user story moves to the QA column ? doing it manually in a team that finishes a lot of user stories sounds like a lot of overhead. I can see a very common scenario where 3 different people finish 3 user stories, one hour apart. Also, can you please describe the life of the Epic in JIRA ? Where does it stay ? Do you move it to Done manually when all user stories belong to it are done ? Thanks for the useful information!
    – Idan
    Aug 5, 2017 at 15:12
  • btw, when you say a user story I assume you mean a sub-unit of a feature right ? a feature can have 5 user stories let's say
    – Idan
    Aug 5, 2017 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.