0

I've been using Jira to deliver software projects using a hybrid methodology and I am looking to improve our current workflow:

To do -> In Progress -> Testing -> Done

Currently, we have a staging/test environment and a production environment.

I am looking to improve the workflow based on the following:

  • Both the tester and myself -PM- take part in the testing phase, and I would like to add a new layer for that if possible
  • I want to add another layer for client review before moving the tasks to Done
  • Handle bugs without complicating the workflow.

My question is how can I improve the current workflow taking into consideration that I am optimizing for simplicity as we are a small team and delivering fast is more important than complex processes for us.

Thanks in advance.

2
  • 1
    I'm not seeing any actual question here. "Here's my situation. I'm thinking of doing X." That's a statement, not a question.
    – Sarov
    Aug 5 at 18:31
  • My question is how to improve the current workflow based on the inputs provided. Thanks for your comment.
    – mlafram
    Aug 5 at 18:42
0

Each stage should represent the dominant activity, in other words, it is okay to occasionally do testing while "In Progress" as long as the development activity remains dominant, and do development while "In Testing" as long as the dominant activity is testing.

Based on what you provided, the following workflow makes sense to me: To do -> In Dev -> In Testing -> Acceptance -> Done

As a PM you participate while it is "In Testing" or "Acceptance".

Having a task hang out as incomplete long after the actual development work is done can be very frustrating and demoralizing for devs. If you are involving clients, it could easily increase the testing timeline by a week or more.

Alternatively, you could create another board for the acceptance phase: Ready for Acceptance -> In Review -> Accepted and then capture bugs in a separate ticket and expedite them through the Development board.

If something was estimated as 5 story points and the dev did all the work in sprint 1, but client testing wasn't completed until sprint 3, your developer velocity is not counted until sprint 3, which can make accurate forecasting and sprint planning more difficult.

There is life outside Scrum, it is called Kanban. You don't have to estimate or do sprints unless you have solid reasons for that.

1
  • Thank you, this is very helpful
    – mlafram
    Aug 12 at 18:59
1

I have two pieces of advice for you. The first is that you need to balance two guiding principles:

  1. Start small and add on as needed, not vice versa.
  2. Your workflow should reflect your reality.

I'm assuming you already have a pretty solid grasp on those, so I'll move on to my second piece of advice:

Ask the team.

While I know you didn't mention Scrum, its Retrospective is perfect for discussing things like these. Always, always, get the team involved in defining its own workflow. The benefits of this are threefold:

  1. Team buy-in of the process
  2. Team understanding of the process
  3. More (and therefore likely better) ideas
0

I am also a product manager and have run into the same issue on my team.

When it comes to adding another stage for testing (i.e. To do -> In Progress -> In-house Testing -> Client Testing -> Done), there is one important thing you need to consider: that 90% of dev work is done before the feature reaches testing.

Having a task hang out as incomplete long after the actual development work is done can be very frustrating and demoralizing for devs. If you are involving clients, it could easily increase the testing timeline by a week or more.

This kind of delay can also mess with your velocity metrics because Jira reports are very black-and-white in terms of things being either complete or incomplete. If something was estimated as 5 story points and the dev did all the work in sprint 1, but client testing wasn't completed until sprint 3, your developer velocity is not counted until sprint 3, which can make accurate forecasting and sprint planning more difficult.

How we have handled it is by splitting bugs that come out of testing (both by employees and by users) into their own separate issues vs. having the initial issue hang out in a testing phase for an extended period of time. This approach puts a bit more of a burden on the PM in terms of creating and managing extra tickets, but makes sure the dev isn't penalized for "not completing" a sprint task.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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