18
Responsible vs. Accountable Roles in a Pull-Queue System
The question you're asking is really an X/Y problem. You have a couple of other problems that you haven't actually called out in your question:
Kanban is a pull-queue system, not a push system. So, unless the API team knows to pull from your "feedback" column, or unless they have their own backlog ...
13
I've seen this happen with design so many times. It's a structural problem with how people and teams are organized. Now, I feel like I should say that cross-functional teams are not required to be agile. Scrum does require them, but I don't see that you are specifically using Scrum. That said, the structure of "Design team creates some design and the ...
12
The main ideas with Kanban is to visualize your work and to limit work in progress. This allows you to maximize flow while at the same time see where you have bottlenecks.
If you started work on something that now needs to stop for whatever reason, you need to remove it from your work in progress. What you do with it depends on what exactly you want to ...
11
Let me challenge the frame of your question a bit:
Why do you have such specific requirements that change for every ticket?
Is it really necessary to have different margins between buttons on different pages? Is it necessary to have different styles for things on different pages? Isn't the job of a designer to create a recognizable style for the whole ...
11
I think this has a canonical answer, at least from a traditional PM point of view if not with Agile or Kanban or whatever else.
If a piece of work was unable to be finished for whatever reason, by the mechanic, developer, trades person, whomever, then the issue falls back to the PM or PM control part of the project to be tracked and resolved. The ...
10
There are two schools of thought about what an Epic is.
Some define an Epic as a large user story, often one that cannot be delivered in a single iteration. However, it can be placed and ordered in a Product Backlog and then be refined by the team when it comes up. The refinement activity will decompose the Epic into a number of User Stories, each of which ...
6
I would recommend against having tasks of equal priority. Use the order in which they appear on the Kanban board to indicate relative priority. This will help the team to avoid having to constantly re-evaluate priorities.
To answer your question: it is really a team discussion around which task makes more sense to concentrate on. However, it would be worth ...
5
From what you are describing, it looks like:
You want your team to be (more) self-organizing and proactive in doing the work, and engaging in conversations with you (the PO) when they spot something missing. You want them to be more Agile.
Your developers are more accustomed to being told what to do and to receive detailed task for which they don't really ...
5
Agile thrives on collaboration between people, rather than building walls around each team and throwing things over it.
The ideal situation would be that the designers work in the same team as the developers and create their designs as the software is being developed, with the technology used to deploy the designs. This way, the designer is the one who ...
5
The CFD shows where you have a potential road block in your workflow. The width of each of color represents how many work items are in each step of your flow, from backlog through done. What you are looking for, and what you want, is generally a steady width of color for each of those steps, except for the first and last step. Eventually, as backlog ...
5
Unfortunately, there is no "right" answer to this question. However, there is a good way to find out the right answer for you. Especially in Kanban, the purpose of the board is to visualize your workflow. Consider a few questions:
Do both teams have the same workflow?
Does the workflow of value delivery mix between teams?
Do you get better visibility into ...
4
I would strongly suggest you ask the team.
The team understands the domain, the way they work, the personalities involved and the nature of your organisation. They are in a much better place to determine the team structure than anyone outside of the team. This is what we mean when we talk about self-organising teams.
Also, don't be afraid of making the ...
4
I just wanted to add a little to Thomas's excellent answer.
Epics are a solution to a problem. The problem is typically: "Our backlog is a bit cluttered and some stories are quite big".
You don't have to use epics, many teams get by without them.
Experiment with how you use epics, but always within the context of the problem you are trying to solve. Are ...
4
Kanban is a pull system. Your PO can push how much they want into a TODO column, but it's still the people doing the work that will have to pull from the top of that column once they have capacity.
When work is pushed, what can happen is that "too much" work is pushed. If it exceeds the capacity of those doing the work, things will start to be ...
4
The purpose of a board is not to give credit to developers. The purpose of a board, especially a Kanban board, is to visualize the workflow.
In this particular case, I see a few possibilities. However, without a full understanding of your workflow, I'm not sure that I can recommend one particular approach.
One approach is to create a "release board"...
3
The new workflow would work if it reduces the load on the designer.
I'm not sure I understand the full picture, but you say:
Due to the designer not having enough time, the team started to work on a lot of stories in parallel. The more stories got finished, the more work was there for the designer. [...] The designer was always lagging, developers were ...
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 ...
3
Do you have a preference for any particular software tool? In Trello for example you can use the Card Repeater feature to have new backlog items created automatically every day, week or month.
3
First - it's not really a user story. Let's call it simply a task. Whether to allow more than 1 developer to work on it - yes. In modern approaches (JiT, ToC) it's more important to finish each task faster rather than have a lot of tasks in progress.
As for whether to split the task for each developer or not.. What's important is:
People understand who's ...
3
You Have More Choices Than You Think
We can't move items backward in Kanban.
Of course you can! Whether or not you should will depend on what "additional work" means within your current process. In most cases, it either means:
Your process failed to complete or expose all the work needed to get a task to the Definition of Done for a given ...
2
Let me go ahead and bump-up my reply to "another answer."
In a "gym application" as described there are at least two entirely separate groups of stakeholders: customers, and trainers. If you looked at a "story" told by either one of them, you would see only the story-teller. You would largely miss why a particular story was needed, because "the trainer"...
2
TL;DR
Your goal of encouraging self-managing collective ownership of the product development process is the right one for encouraging team agility. However, the team as whole appears to lack sufficient experience (and possibly the teaming skills) required to fully embrace agility.
The solution is essential to find the X in the implicit X/Y problem. That ...
2
In addition to the tips above:
Vertical distance across or between color bands represents the amount of WIP in those stages at that time.
Horizontal distance across or between color bands represents the average lead time across those stages at that time.
The slope of the lines represents the rate at which something happens (which should be more or less the ...
2
You're acting as if your bottleneck is something bad and you should rid of it. This may be true, but I'd like to list other options. There are 3 approaches to dealing with constraints:
Improve their performance (Bogdan got it covered in his answer) (book)
Use them to dictate the performance of the system (same book)
Use them to pivot your business (another ...
2
To effectively answer this, we have to remember that the purpose of a Kanban board is to visualize the flow of work. It is not quite as 1-to-1 as each column being a step of work, but that's a good place to start.
A and C are fine because they are not columns per se. A is part of the Development step and C is part of the Testing step. The soft line just ...
2
As per the screenshot, my team should finish issues in the order 1-3-2, right? 1st issue should be delivered before starting 2nd issue, right?
No. The backlog in a Kanban board is ordered in order of importance, so the most important stuff to work on next should be at the top. This mostly tells you something about the order in which tasks are started, but ...
2
There isn't any rule, the team decides on how they work and how to signal different things occurring.
As you mentioned, you can add dots on the issue for each day it stays on the board, you can use different colors for the issues you will want to pay more attention to, if you have a physical board you can you can tilt the card from this ■ to this ◆, and the ...
2
in Kanban we treat the older task as more important
Close, but not exactly. If those tasks are being developed in parallel - it's okay to finish the later task sooner. What JIT (aka Kanban) actually says:
Once we started - we need to finish any given task as fast as possible (decrease Lead Time)
The amount of work in-progress (started but haven't been ...
2
The Kanban Method defines the whole notion of Upstream Kanban, which is the application of Kanban to upstream processes, especially backlog prioritization and grooming. The process of prioritizing stories is a continuous one in general. However, Product Owners can choose to prioritize the next set of stories in sync with the dev team's delivery cadence.
In ...
2
If some of your items don't need review (although I think that's a bit unusual for a development flow), you can split your Development column in three sub-sections, something like this:
Todo/Backlog
Development ( Doing | Ready for review | Ready for testing)
Reviewing
Testing
Done
Once a ticket has completed development, you decide if the ticket goes to ...
Only top voted, non community-wiki answers of a minimum length are eligible
