Steps for moving from waterfall to agile
Looks like you have made the two most important decisions for transforming your software development process:
Moving from waterfall to agile.
Following the Scrum (or a modified Scrum) process.
Congratulations! You are on the right track. It is possible to work out the other steps from here.
I would say, in order ...
Scrumban is really just the application of the principles of the Kanban method on your Scrum processes. Kanban's fundamental principles are -
Visualize your current process
Implement WIP Limits and the Pull method; and
Improve Flow by addressing any process bottlenecks and evolve gradually
So, the fact that the team wants to retain the tenets of Scrum ...
There is no clear indicator this question belongs to Sprint Backlog only.
I believe this is wrong.
The urgency of the work, to me, implies that it cannot wait until the next Sprint. The team must bring this work into the current Sprint and therefore is responsible for making the determination on increasing the WIP limits. Since the Development Team owns ...
What Scrumban Really Is
Fundamentally, Scrumban is a management framework that emerges when teams employ Scrum as their chosen way of working and use the Kanban Method as a lens through which to view, understand and continuously improve how they work.
Scrumban is distinct from Scrum in the way it emphasizes certain principles and practices that are ...
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 ...
Update: This Answer assumes, incorrectly, that by WIP the OP meant Sprint capacity (a limit on how much work can be included in a Sprint), not Kanban WIP limits (a limit on how much work can exist in a single status at a time). I'm leaving it for posterity, but it does not answer this Question.
I would argue that the only valid answer is:
No one, as '...
The two approaches actually solve different problems and are fairly compatible with each other if you happen to have both problems.
Scrum is designed to solve complex-adaptive problems. That is, problems that are difficult or impossible to quickly identify the best solution for, moving targets, and problems where you understand the problem better the ...
I'm not sure what is unclear. From your own reference:
Throughput: The number of work items “finished” per unit of time.
So if you get asked: "How many units do you finish in an amount of time", this would be the obvious metric to make predictions. "We finish 5 units per day on average, so we should be able to finish around 30 by Friday next week".
FWIW, let me add another response here.
I would have answered the question slightly differently from Sarov in that I'd say "...one approach would be to have it same as Scrum, except with a Kanban style visualization board, and Kanban concepts of WIP Limits and Pull."
Kanban is not a software or project management methodology by itself. It is a ...
Both Scrum and Kanban have well defined processes and constraints.
ScrumBan, however, is not so clearly well-defined. It is, put loosely "something in-between Scrum and Kanban".
If you want a potential example, one approach would be to have it be the same as Kanban, except with sprints. You have a 'backlog' column on the far left, and a 'Selected for ...
There's too much going on in your question to give concrete advice but here are some basic rules I usually apply:
If a project is complex or complicated and non-repeatable, use scrum.
If your project is simple and/or repeatable, use whatever process method you prefer
If your project is in chaos, do anything but get out of the chaos and into the simple, ...
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 ...
It depends on what is going on in your company or more precisely with your team. If you have 'heavy' product development activity, then 'Scrum' is suitable. For production support, Kanban is better. If you would like to address your issue along with your regular Scrum activities, you could rotate your resources (probably on a daily basis) for production ...
Scrumban is a slang term, not an codified process, so it's hard to say exactly what it is. However, I can say that I see a lot of success in Scrum teams that adopt some of the principles and practices of Kanban. Some of those that help Scrum teams include:
Visualize Your Process: Many Scrum team task boards simply read Ready-Doing-Done. This rarely reflects ...
Scrum works well for projects that:
Have relatively stable requirements - such that they don't often need to be changed inside a sprint
Team sizes from 3-9
Have a stable team that has the time to learn and adopt a framework
Benefit from a regular time-box (the sprint)
Kanban works well on projects that:
Have changing priorities
Frequently have new ...
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 ...
Henrik Kniberg and Mattias Skarin have written a short book about similarities and differences between Scrum and Kanban, if you are interested. There is also a summary from Henrik Kniberg found here. For a TL;DR you can jump to page 48 of the summary where you will find this:
If you look at the Kanban differences, where there is no lock down into iterations ...
I'd put it slightly differently. Scrumban is the (by now) fairly well-established term being used by many experienced/ respected thought leaders in the Lean/ Agile industry for work done by teams when they apply Kanban principles to their Scrum-based software development work. The basic premise of Kanban is to help teams improve, whatever be their method of ...
The existing Answers are good, I just wanted to add something on top of them.
As you're doing Scrumban, I am assuming/hoping that you are performing the Scrum event known as the Retrospective (often considered to be the single most important part of Scrum).
Therefore, whatever you take away from this, other research, and your own internal musings, I suggest ...
I would like to challenge your assumption that this has anything to do with the WIP-Limit.
Lets say you have 5 full time developers and 2 part time developers. And for starters, you set the WIP limit to 7, so that each can concentrate fully on their one task until it's done.
Whether or not the part timers are there on any given day does not change ...
I believe there's a simple solution: All Part timers must pair program with full-time developers...all the time. But that seems heavy handed?
I have worked with teams that pair on all work and it has been highly effective.
The developers will need to think carefully about how they pair to ensure they maximise the benefits of this approach.
There are lots ...
Both Kanban and Scrum share some of the same principles, including:
Both are visual
Teams practicing either are self-organized
Both focus on the concept of continuous improvement, uncovering
Both create future commitments, aiming to be as accurate as possible
with delivery of work
However, they also have distinct differences, including:
My answer would be
No one, as 'High Priority' work is not a valid reason for changing the WIP during the Sprint.
The WIP limit, as in the number of tickets that can be in a particular status of development (a column on the board) is not determined by the urgency of the work but by the amount of work that the team can be working on at the same time ...
My other Answer answers a different question that the OP has clarified is not what was intended to be asked. I'm leaving it for posterity. This Answer addresses changing the Kanban WIP limits during a Sprint.
In this case, I would argue that the best answer is not actually listed. There are two aspects to this issue.
What to do about this particular high-...
Scrumbut is not a methodology it's a term used when people pretend to be doing scrum or are unable to implement it properly due to organisational issues.
You could also think of Scrum but as a way of working whilst you are transitioning to Scrum
Any way don't get too bogged down with the methodologies concentrate on the agile principles and create ...
Besides the differences mentioned before, I find that what really separates Scrumban and Kanban are the several rules that it takes from Scrum. While Kanban is loose and Scrum is strict, Scramban braces the middle and provides an option for a somewhat controlled Kanban process.
Instead of having no ceremonies whatsoever, Scrumban keeps the tradition of a ...
There are circumstances where Scrum is not well suited. One of those circumstances is where the team regularly get ad-hoc or emergency requests that have to be addressed quickly and the request cannot wait for the next Sprint. In these circumstances, I recommend Kanban.
One thing I never recommend is to try and smash two different approaches (Scrum and ...