A redditor asked the following question:

Question#

Story Progression Workflow in Gitlab

I created some scoped labels in Gitlab to assist with the workflow getting stories into the Sprint. They are below. Any suggestions?

  • Product Backlog - Discovery
  • Product Backlog - Ready for Refinement
  • Product Backlog - Refinement
  • Product Backlog - Ready for Sprint Planning
  • Sprint Backlog - Ready for Sprint
  • Sprint Backlog - In Progress
  • Sprint Backlog - Blocked (This might just end up a simple label)
  • Sprint Backlog - QA/Testing/Validation
  • Sprint Backlog - Ready for Review
  • Sprint Backlog - Done - Potentially Shippable

My answer#

Nice waterfall. 😉

Then the OP asked a question:

Ok so then just In Progress?

tl;dr: For delivery - yes. For discovery, I don’t know. I don’t know how to solve the product discovery problem, I’m not an expert.

But in the case of product delivery, I have some experience. I’m a big fan of Continuous Delivery and eXtreme Programming. In my team we use Scrum, but because Scrum is just a thin framework, we have adopted a lot of practices, mostly from CD and XP. During a sprint, each sprint backlog item (user story or whatever we call it) is always broken down into small, deliverable tasks during a few hours. When we start the sprint, we only have a rough idea of how we are going to do it. We usually add tasks as we go along.

There are usually a couple of people working on a task that is part of a larger story. We use pair or mob programming and TDD. So the code we write is already reviewed and tested. When the small task is done, we merge and deploy it. We have a couple of deployments a day. We usually release a story when the implementation is production ready. Sometimes, some users get access before the final release.

That’s why I think your process looks like a waterfall. In my opinion, phases like development, testing, review extend the feedback cycle. When the developer says the code is done and ready for testing and review, he has to wait for people, then it goes back to the development phase to make some fixes and improvements.

I think it is better to review and test as you write code, and write it in small batches. You don’t have queues and handoffs, instead the quality is built into the development process.