7
TL;DR
Yes. There is no issue with this at all.
Discussion Points
The concept of Epics are pretty amorphous and undefined. You can find descriptions of Epics as large user stories that need broken down and in that regard, it is common for some to try and squeeze them into a release train window.
For instance an Epic may be a container for a specific ...
6
Because Kanban is not a full framework for developing products in itself (it's a method to optimize another process), there are many things it doesn't specifically account for. However, teams often track throughput in either item count or even story points if they chose to use them. You can forecast release timelines with either item count or story points ...
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
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 ...
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"...
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 ...
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 ...
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
"Allowed" by who/what?
Allowed by Scrum? Yes.
Scrum is a framework, entirely encompassed by the Scrum Guide. There is avast array of processes that Scrum does not prescribe, assuming/allowing/forcing individual Teams to figure them out for themselves. This is one of them.
Allowed by Kanban? Yes.
Kanban is even less prescriptive than Scrum. Kanban ...
3
If you really want to do this, you could base the swim lanes on queries. And use either a label or the flagged field to decide if something should be in the On Hold swimlane or not.
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
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 ...
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
This is the type of project where it pays to spend some time at the beginning to identify external dependencies. A dependency is a potential risk, so if you can identify the nature of the external dependencies, you can put something about those characteristics in the contract with your partner organizations.
To expand on my comment above, you might for ...
2
With Scrum you can try to plan longer releases using team velocity. If
team velocity is 100 Story Points (SP)/Sprint and the Product Backlog
has 1000 SP then you can say you can finish in 10 Sprints.
Theoretically, yes. In the real world, though, if you can have your scope of work so well-defined, why are you using iterative and incremental methodologies? ...
2
Daniel is spot on, feel free to add story points to the process if that helps you estimate the delivery time better. But similar sized tasks and average cycle-times will probably give a similar range without the time put into estimation.
I think that typically when using Kanban you would release when you see fit. So either you pick a date and release ...
2
Being a small team, take one project at a time
You said you want to embrace 'WIP limits' principle of Kanban among others. The reason why Kanban recommends WIP limits is to help the team focus and to minimize context switching. Instead you are flying very far in the opposite direction:
Use two boards in parallel? Create a 2D Kanban board? Embed one board
...
2
Your list is really good already. I particularly like the last one; If the stakeholders and product people are happy, chances are things are going well.
Other things you might consider would focus on the elements that differ between Scrum and Kanban.
For example:
How frequently do we need to make changes to priorities at short notice (if this happens a lot ...
2
Visualization ≠ Dependency Management
Visualizing the work is a technique, and generally solves for a problem that this group of individuals may not actually have. To find value in a solution, you first have to determine what problem you're actually solving for. While I suspect the problem is dependency management, that's not self-evident from your original ...
2
You could split the ticket in two. Lets say you have to deploy an application and that means you have to request access. Granting you access can take an amount of time unknown to you.
You could split that into "Requesting access" and "Installing Application" where the second ticket cannot even start before the access is granted. The point ...
2
In Kanban, how can we break down work?
You first need to answer
In Kanban, why do I break down work?
Is there any specific reasons to break down the work? How would this help your team?
Then, for each reason, you might want to answer:
How can I restructure my Kanban so that I can cope with this problem?
Can I address this specific problem instead of work ...
1
Open source software for Scrum/Kanban
Here are two open source options for software project manangement using Scrum/Kanban.
Tuleap ALM: See the Explore Tuleap Community Edition section for more details.
Taiga on-premise self-managed
However:
You need to pay for the hosting provider.
You need in-house skills to install, operate and maintain these software.
1
I am assuming that the projects you are working on are small / medium Scrum projects.
Google spreadsheets or Excel Office 365 (to enable online collaboration) could be an alternatives.
You could google search for managing small/medium scrum projects using Google Spreadsheets templates(free) or MS Excel templates to be used with Office 365 for sharing(paid).
...
1
Just-in-Time (I wish people stopped saying Kanban) requires all tasks be of the same size. It doesn't matter which size it is (though usually smaller sized tasks are easier to manage & predict), but there must be only one. Otherwise you can't measure WIP limits in number of tasks, which in turn means you don't know how to balance the work across the ...
1
Great question!
Kanban works best when all tasks are a very similar size. Your team's velocity is simply the rate at which they complete tickets. This makes predicting effort reasonably easy.
Which ticket size to use? From experience, 3-5 days works quite well. If a ticket is larger than 5 days, we split into smaller tickets. If a ticket is only 1-2 days, we ...
Only top voted, non community-wiki answers of a minimum length are eligible