Where to put those cards that are finished during the day in Scrumban?

Question

I've successfully implemented Scrumban. I implement the daily scrum meeting and retrospective. I love how easy the Kanban board is that it helps for the whole team to know where are we now at the moment and also to know how far are we before hitting the milestone.

There is something that keep me wondering, if I have ticket that came from a column called "Backlog" and put it under column "Doing", once my team already done working on this.

Do they move the ticket straight away from "Doing" to "Done"? Or, we as a team will do it during the daily stand up meeting? Then, from there we will move all the tickets?

Answer 1

Some of Scrum teams have a "ready to discuss" column between "Doing" and "Done". They put finished cards into this column, discuss them during the daily meeting, and when the discussion is over, they move them to done. I believe this kind of column can help you.

If you don't want to introduce a new column, increase the size of the "Doing" and put the ongoing work items to the left side of the column, and put the finished items to the right side. You can read more about it here.

Answer 2

I would let the team do whatever is convenient for them, then challenge and ask them about it during retrospective. Retrospective is the perfect place to help the team evaluate their current practices and possible improvements.

It sounds to me like the real issue here is "why are we working on and finishing issues that aren't in our Doing column?" Kanban and Scrum both only work if their boards/cards/issues/whatever are accurate and visible. As scrum masters, our power comes from shedding light on situations. If the team is skirting that light, then you can't help them adhere to the rules in place.

Answer 3

I'd recommend marking the story in "doing" as ready to pull, assuming moving the card to done signifies that parts of the story meet the team definition of done or acceptance criteria. Many Kanban teams will have a pull column or sub-column to indicate work that is done but has not been pulled to the next active state. This can create a buffer and also provide some additional granularity on when bottlenecks occur between active states.

The person or people that pull the story into done are then validating the card is "done done" versus the person/people that delivered the card saying it is done.

This forces a feedback loop between the people delivering the work and those consuming it to ensure everyone is on the same page. If the producers are the consumers it may be beneficial to pull cards in front of the entire team during standup to ensure the team is aligned.

Answer 4

As the previous replies have stated, the story shouldn't move from doing to done until you are happy that it has satisfied your won DOD i.e. definition of done.

As an example of that, here is our current DOD from one of our projects. You can make your own and add as little or as much as you want but it will help to have an agreed definition so that everyone on the project knows what state the code is expected to be before release.

• User story kick off meeting held
• Test fixture authored
• Code developed
• Builds without errors against latest version of workspace
• Unit tests written and passing
• Peer reviewed or produced with pair programming
• Demonstrated to tester at developers desk to confirm test fixture honoured
• Code checked in and unit tests run against current version in source control on build server
• Deployed to UAT test environment and passed system tests
• Passed UAT and signed off as meeting requirements
• Any build/deployment/configuration changes implemented/documented/ communicated
• Relevant documentation/diagrams produced and/or updated
• Remaining hours for task set to zero and task closed

Answer 5

In the true spirit of Kanban applied to Scrum, I'd say you should -

1. Start with what you do now (or what you did before applying Kanban/ Scrumban)
2. Visualize your work/ workflow
3. Manage the flow of work
4. Improve gradually, as opportunities for improvement present themselves.

What makes sense for the team and for the stakeholders for whom the team is working should help you decide how the work should be managed on the Kanban board. For example, do stakeholders look at the board during the day and wonder "Is my work done?"? If so, perhaps it makes sense for the team member to move the ticket to Done as soon as they ARE done with it. During the standup the next morning, the team member can simply provide an update on it - or whatever else they need to do.

On the other hand, does the team-members or the stakeholders wait for the outcome of the standup to get their updates? If so, (continue with the practice and) update the card status during the standup.

Is getting an accurate measure of your cycle time important? If so, perhaps best to move the ticket to the Done column the moment it is done instead of letting it wait overnight in the Doing column. Depending on the nature of your work, tickets might move to a "Customer Acceptance" column or a staging/ demo column where the customer/ product owner can be given a demo.

Sometime back, I'd written a blog post on a related topic - "Does your Kanban Board reflect the process you actually have?" You might find it interesting.

Ultimately, it just really depends on your processes and what you are trying to measure and improve.