Suggestions for workflows for a scrum team

Rosana Casilli

Good morning all!!

I need some suggestions on worfklows for a scrum team. 

I have seen a lot of workflows used for differents teams but I want to have some suggestions from you, the experts ones.

There is a new team, it is working with a workflow:

To Do -> every issue in the current sprint

In progress->  when dev team start working on it

QA Testing  -> when dev team finish its task they move to QA Testing

QA In Progress -> when testing team start testing and it could go back to In Progress

Closed -> when all acceptance criteria have been validated

There is also a Blocked status in case some of the issues should be blocked for some reason

All issue types (Epic, Stories, Tasks, Subtask and bugs) have the same workflow

 

Analyst work on backlog, there is no task or story to represent their work, so what they do i write the documentation related to the Story and in the daily meeting they told the team if they have finished it or not. These stories remain in backlog till the next sprint planning so they can be estimated

Any story in sprint is considered finished an ready to be assigned to a developer.

Is this a goo approach? 

Which other approch could consider taking into account best practices?

 

Thanks in advance for all the suggestions!!!!

 

regards,

Ro

 

 

padraik

There's a lot that goes into this.  I have consulted for quite a few companies and while all of the scrum workflows "taste the same" - none are identical because of the small differences in how organizations work.

From your writeup, I see that you have analysts working on the backlog and approving them.  My favorite solution to this is a workflow that covers the full lifecycle of the ticket, and uses separate boards to focus the "teams" on their part - Here's an example of a workflow for "Story" that spans  the Product, Development, and Release phases of the lifecycle.  It's possibly more in-depth than you want, but it's a great illustration of what I'm explaining

There are four separate Boards for this project:

• Product Board
  • This is the working board for our team of analysts, and does not display tickets that have made it to the next phases of the workflow
  • Four columns, with one status matched to each column
    
    • New (consider this the backlog for our Analysts)
    • PO Review (when the Product Owner is working on the ticket)
    • Stakeholder Approval (ready for the stakeholders to approve)
    • Stakeholder Signoff (the ticket has been fully approved for Dev)
• Handoff Board
  • This board facilitates the meeting between Product and Development when tickets are reviewed and accepted into the Dev Team Backlog 
  • Two columns, one status in each
    • Ready for Development (the actual status is "Stakeholder Signoff" meaning that when tickets make it to the last column on the Product Board, they also show up in the first column of this board)
    • Dev Backlog (As each ticket is reviewed and approved, it is transitioned to this column, which holds the status "Ready To Work"
• Dev Board
  • This is your standard scrum board, We use "Ready To Work" as the first status for the board, again shared with the last column of the Handoff Board.
  • Six columns, one status in each
    • To Do ("Ready To Work" status)
    • In Progress (Developer has begun work)
    • Dev Review (Code review, Pull Request review, however you like to call it)
    • QA (Functional testing)
    • Final Approval (This is when the Product Owner/Analyst reviews the finished product and accepts is as meeting the acceptance criteria)
    • Done (Count the points for the sprint - we also required a field "Needs Deploy" to be set to Yes or No for this transition
• Release Board
  • Finally, this is the board for our DevOps team.  The first status for the board is "Done", and the board query is {project=XXX AND "Needs Deploy" = "Yes"} so that only tickets flagged for deploy appear
  • The remaining steps were defined by working with the Dev Ops team

 

Hopefully this makes sense.  It is one workflow that tracks the full process.  Each "team" (analysts, developers, devops) only focuses on their board, and when they finish their work, it automatically feeds the next team's board.