1

I'm tasked with customizing the ticket statuses and kanban board for our software development project.

I realized that Microsoft Kanban Boards and actually all other kanban boards I could find only show one deployment step. It is always something like: New -> In progress -> Testing -> Deployment -> Done

How do these teams keep track of their deployment statuses? After our developers test the new function it is deployed to the stage environment. Then on stage we do the UAT and then there is a queue for the next prod deployment.

Why do other companies kanbans not seem to have a "ready for stage deployment" and "ready for prod deployment" state? I need to know which tickets are to be deployed for executing the next deployment. I also do not want to lose track of my tickets after the deployment to the development server. I want to know if it passed UATs or not and if it is on prod.

What am I missing?

5
  • 2
    Why do other companies kanbans not seem to have a "ready for stage deployment" and "ready for prod deployment" state? Who cares how other kanban boards look like? Customize your Kanban board to support your process and how your team works. Everyone's kanban boards are different. – Bogdan Aug 12 '20 at 17:30
  • Yes, of course I should customize it to support our needs. The thing is that I haven't done that many software projects yet and was wondering why my needs seem to be different than anybody elses (for this specific matter). For all example projects I checked, the process ends with the deployment and I would really like to know why that is. As far as I know Microsoft also uses Dev -> Stage -> Prod so why is that not reflected by their kanban board? – MajinBoo Aug 12 '20 at 18:08
  • 1
    Maybe because example projects are just that, examples. They explain how to use the tools, what the flow is, what the principles are, etc, and that's their purpose, and not necessarily to explain a real process, for real software. – Bogdan Aug 12 '20 at 18:43
  • Microsoft shows one of their actual kanban boards here. As you can see it also only includes one deployment stage. Even the example you posted only includes one deployment. – MajinBoo Aug 12 '20 at 21:14
3

TL;DR

There's no right or wrong answer here in terms of what activities, columns, and swimlanes belong on a given Kanban. However, it's likely that your process is being driven by a software tool choice rather than reflecting the actual workflows and working agreements in your process.

You should carefully evaluate whether you have captured the right abstractions for your process. You should also ensure your Kanban queues effectively track flow and continuous improvement for each team rather than work done by other teams.

Analysis & Recommendations

Kanban is based on queues and flows, but it is based on your queues and flows. It is arguably inefficient to have pre- and post-queues or multiple state transitions for each activity, so many experienced practitioners omit them when they don't add measurable value.

In addition, many Kanban practitioners today are doing so within a more agile context. Kanban-the-framework (as opposed to various Kanban practices, artifacts, and methodologies that are more widely adopted) is often more aligned with Lean Manufacturing than with small-team agile frameworks such as Scrum. As a result, the columns of a single board are generally aligned with activities directly performed by the team, rather than holding all possible states extrinsic to the team's internal flow.

If your team handles UAT, staging, and production deployments directly, then you should certainly reflect those flows in your Kanban. However, if those activities are externalities handled by others, then the work should be moved to the appropriate Kanban (e.g. not yours) when the team is done with it. In such cases, it's often more appropriate to mark the work as "done" by the team, and then get fed back smaller items such as next-stage deployment tasks (perhaps handled by a separate swimlane with its own WIP limit) rather than continue to track work that is performed outside the flow represented by the team's Kanban.

With Kanban, one size definitely doesn't fit all. Without knowing why you've chosen the level of abstraction that you have for your workflows, and understanding all the metrics that you're tracking to determine whether or not that abstraction is useful to you, then it makes no sense to compare your abstractions to someone else's.

All models are wrong; it's just that some are useful. What you need to ask yourself is whether your model is useful. If not, focusing on diseconomies between processes (rather than treating all activities as internal, especially when they aren't) is a good use of your team's inspect-and-adapt loop.

3
  • Thanks for the detailed answer. My team does handle development, UAT, staging and production, and that is why including these states seems obvious to me. Reading your comment makes me think that I'm on the right track. Although, it still seems unintuitive/odd to me that many teams seem to close their tickets after the dev deployment. Afaik UAT are often done on stage and I think it is great to have the original user stories and test cases during that phase. – MajinBoo Aug 12 '20 at 19:12
  • @MajinBoo, please consider the possibility that the "Deployment" column actually means "deploy to production" and that the other deployments are considered to be implicit in, for example, the "Test" and "In Progress" columns. – Bart van Ingen Schenau Aug 13 '20 at 7:16
  • @BartvanIngenSchenau I considered that but in that case, how do we know which tickets have been deployed yet and which haven't? – MajinBoo Aug 13 '20 at 7:37
0

Many companies nowadays don't bother with the deployment step because it's too trivial. With the advent of Continuous Delivery for many of us it's just a click of a button.

Also Just-in-time (Kanban) implies keeping your Inventory Costs (Unfinished Work) low - so the number of tasks waiting for release is 1 (best case) or several of them - which is not hard to keep track of. Thus when your Testers finish testing they know that there are 2 tasks to release - they just go ahead and deploy to PRD. In such scheme there's no "big list of tasks pending to be released".

If your process is more complicated (there are activities after functional testing) - then you'll probably have a column for those activities and testers will move the task to that column. Again - deploying to the respective env is a matter of a click of a button so there's rarely a need for an extra column.

2
  • We do try to keep the unfinished work low but it still adds up to about 8 tickets per deployment. Of course the deployment itself is very trivial but I still want to know what tickets are ready for deployment / are about to be deployed. Theoretically I could also write down these 8 ticket IDs with pen and paper and keep track of them the old fashioned way but I think using a state in the ticket system to keep track is more comfortable. – MajinBoo Aug 13 '20 at 17:59
  • Then you could either have an intermediate column "Done" (ready) vs "Closed" (delivered). Or have only one column "Done" (ready) and then remove the task from the board once it's deployed to PRD. – Stanislav Bashkyrtsev Aug 13 '20 at 18:20

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.