Work item management and workflow

Processes
#1

Morning All, I am interested in getting some thoughts on how “work items” (bugs, PBIs, user stories - whatever you call them) are managed in your workflows.

1/ When testing a userstory/PBI and you find an issue would you typically log bugs as separate tickets, or do you (at least for blatent failures of the AC) just pass the user story back and not log separate bugs.

2/ If your process is to log bugs then would what do you tend to do with the user story ticket whilst the bugs are being fixed? Do you keep it with the tester, change state etc, or do you also send this back to the developer

Appreciate any thoughts or input on this.

2 Likes
#2
  1. In one company I did not use tickets for bugs or found things during testing. My preferred way to debrief to the developer and add some short notes in the ticket.

If there were a few findings, then a quick glance was sufficient to scan the notes. Sometimes there were many bugs, then it became harder to track, which items were solved.

A solution was to make a summary of all tests with the latest status. This way it saved a lot of scrolling and missing unresolved issues.

The ticket remained in the Test column. It had to be solved as soon as possible. It was not assigned to the programmer.

A lot of paperwork was avoided and standards were still maintained according to the auditors.

  1. In another company I made a ticket for each unique bug I found. Once I got the feedback,that the cause was the same for a whole group of bugs.

In this company people were used to assign tickets to people to change the status of the tickets.

1 Like
#3

Thanks for the reply.
My “problem” is that a/ I want to be able to differentiate between work items which are “To do”, “In progress” and where testing has completed but we’re waiting for bug fixes/rework and b/ I don’t want unnecessary work items being created and passed around (more to manage). Currently, I tend to assign both bugs and the user story back to the developer but feel this is unnecessary (i.e. their work is being driven by the bugs at this point and not the US so why to assign that back? - It’s only for reasons to have an easy to manage Worklist.)
I always liked the idea of logging comments and sometimes this is what we do if there is a blatant fail, but the issue is (like you say) when you get a number of issues (especially if the user story isn’t a “small” one) they can get lost in the discussion thread. (Maybe a solution here is to have an “Issues” box in the template for the US and then log bugs and issues in there instead)
Ultimately I think the answer I like best would be to have different statuses that are easily distinguishable but I know that isn’t favoured by all.
Also, the level of collaboration plays a lot in the way these are handled - I really like you’re approach of discussing with the programmer after testing, but that isn’t always an option for us.

1 Like
#4

It is not my approach. It grew that way.

One of the developers asked me to notify him when I noticed something strange. If I would continue testing from that point, then it became difficult to determine the state of the program. At that moment the developer could still view the database, have a look at my input file, and talk about my actions.

The next step was the debriefing. He did not like bugs in his program and I helped him to find them.

My test charters were too long to scan. So the developer lead asked for summaries. He also adopted this way of reporting his own test results in the tickets.

While pondering about this reply I remembered a Lean Coffee session with Lisa Crispin. I could change things with experiments. The important thing is to involve the other people. Like you said, it is about collaboration.

#5

I’ve had the ‘pleasure’ of being a JIRA admin at a few different companies in which I have worked.

And while JIRA isn’t the be-all-end-all of tools, it is what a lot of us use, the workflow customisation can be pretty powerful, but also really mess things up.

Bug handling should be something that the team help to define and work with. For some teams, I have seen that they only raise a bug in JIRA when it won’t be worked on that day, others want to track them as child-tasks of the user story and others want them to be raised completely separately.

There isn’t any one right way to do this, and the dynamic of a team may change and so the process should also.

This is a very long winded way to say that you need a conversation, you need to try different things out and see if you can’t change it up to make it work for you. If it is a more corporate, or multiple teams then your flexibility to do more will be reduced.

What I can say is that I dislike them added as comments in a user story in general, and if they are items that are either candidates for automation or regression checking, then it makes sense to have something to trace their origins, if only from a high level.

I don’t even know if this makes any sense at all?

#6

It does, thanks for the reply.

I think my main issue is that we are constrained a little bit on the work item workflow (decided by development manager) but it’s really what I want (as a Test lead). Just trying to gauge a bit more about what people do really in other orgs.

I think my main sticking point is around the user story (or PBI in our TFS world) - if you fully test the US/PBI and find bugs then the bugs become the unit of work for the developers then what happens to the US. I need (want) to be able to differentiate items that still need to be tested vs ones which we’re waiting on bug fixes. Seems like additional states might be a better option really to help manage the work items a bit more.

#7

I appreciate the context.

When we created the child task (that we called a story bug), that had a ‘light’ version of the workflow that was applied to user stories.

The bigger challenge is always with the people, no one person should be making the decisions on workflows, it has to be collaborative.

Have you collaboratively created/defined what PBIs are, what they should contain, what their workflows should look like, things like definitions of ready and done?

The DoD is useful as a way of ensuring that a user story isn’t considered done until everything, including bugs raised and testing completed is considered Done.

It’s always a surprise to me when I start in a new team and that DoR and DoD aren’t well defined or understood. Also you need to be wary of gamification of these sorts of things regarding KPIs/metrics.

In my current context, we have different DoDs and DoRs for different PBIs. I have worked in places where we added additional states to the workflow, but once we did that we found that many were being skipped, so be prepared to try things and then change them. Use meetings like retrospectives to challenge the status quo and raise these concerns and see what you can do. In reality, no ideas are stupid, you just need to find one that works in your context.

1 Like
#8

Thanks for the reply.

1 Like
#9

Just curious, I may be terribly wrong here, but,

Isn’t all that’s happening with a user story part of the user story?
If there’s a bug related to a user story, shouldn’t it also be part
of the user story in some way? Is there a way to ‘attach’ all the
bugs related to a user story to it, so that you don’t need to deal
with work items related to the user story separately (which I think
creates a lot of clutter and less efficient) ?

1 Like