In my last article, I began a little comparison between Scrum and Kanban: What are the key similarities and differences between the two methods?
This time, I’d like to talk a little bit more about the distribution of boards to teams, and how to work on different products at the same time.
This blog post is based on the previous one. If you haven’t read it until now, I suggest doing so before going on with the rest of this article.
As mentioned in part 1, a Scrum Board always shows the state of the current sprint for a certain team. At the end of each sprint, a new “potentially shippable product increment” is created, the items on the board are “reset”, and the next sprint begins. As a consequence, requirements to be implemented by a Scrum team mustn’t be more than one sprint in length. Bigger chunks must be split into smaller ones until they fit.
In Kanban, this is handled differently. As sprints do not exist, items can be of arbitrary length. Also a result of lacking sprints, a Kanban board doesn’t undergo the same cycle as a Scrum board, and is not reset after each sprint. But there are some similarities, however: The rows contain the various requirements, and the columns represent the states of the workflow. Requirements are “done” as soon as all tasks associated with it have moved to the right-most workflow state.
<———————————>
This is not the only difference between the two panels: In Scrum, the table exactly the work of a team again. While it may all see the blackboard, but the team may also change. The team is cross-functional occupied. I.e. all the capabilities needed to the current sprint to a successful conclusion, are included in the team.
In KANBAN are here from the outset, no such limits. Cross-functional teams are optional. Even the restriction to a single team is not required. Instead, it refers to a Kanban board to a specific workflow. A workflow can, in principle, but also include several teams. A Kanban table may be purchased by several teams changed.
To say it is better to be able to imagine, the whole thing again here graphically:
A Scrum-table is always in possession of a single team
Figure 1: A Scrum-table is always in possession of a single team
Figure 1 shows a typical Scrum board. She is always in possession of a single team. All columns of the table will only be changed by this team.
Figure 2: A Kanban board of several teams can be managed simultaneously
Figure 2: A Kanban board of several teams can be managed simultaneously
Figure 2 shows a Kanban board. It is not only not in possession of a single team. Instead, it reflects a workflow again (in this case simply “Todo -> Processing -> Done). The individual steps of the workflow may be arbitrarily divided in teams.
In this example, here is example the column “Todo” by only one person managed (which could, for example a kind of project manager or his Product Owner). For the remaining columns, however, is another team responsible. In reality, the board would be from Figure 2, probably a bit expanded to really useful to be able to work. Links of column 2 “Todo” could be a column about “backlog” to introduce a kind of disordered wishlist without prioritization, as the pool for all future requirements serves. Should any of the requirements to be realized, it will be easy for “Todo” postponed.
Of course you can have the workflow to many other types of distributed teams. With a high number of items it might be useful to some, that two or more teams share a column. But the Scrum used in case (a team manages the entire table) is possible.
A Scrum-table is really nothing other than the special case of a Kanban board.
Behaves similarly to the case also with the estimate of items, or their lead on the table:
In Scrum, use the length of an iteration as a frame of reference. This means that the team appreciates all the new incoming requests and selects them exactly as many as it is in this iteration (sprint) can be implemented. If one adds the estimated values of all the requirements of a sprint, so you get the “total value” of a sprint (in Function Points). We call this number also “Velocity”. This value can then several sprints continued to write and compare. He serves the team as a clue in the sprint planning when it comes to requirements for the next sprint to select.
Figure 3: Calculation of the Velocity
Figure 3: Calculation of the Velocity
In KANBAN, however, this is a bit different. Since it is of no house of iterations, and also the new requirements Beschätzung is not absolutely necessary, there is no fixed reference frame, one to calculate the velocity would use. Instead, we need to manage differently here. Some teams such requirements are grouped into so-called “MMF” (Minimum Marketable Features). Then they measure the time it takes all the requirements to implement this group. On this basis, can then also service level agreements (SLAs) are working. “We provide a MMF always at max. 10 days would be an example of this.
Other teams break requirements (without explicitly beschätzen) in approximately equal-sized pieces and then measure the throughput. Based on a fixed (arbitrarily chosen) time can be once again a “Velocity” calculate ( “10 requests per month).
The possibilities are almost limitless. One can of course always a fixed frame of reference to introduce, with estimates and / or re-iterations of a Scrum-like method come. The best way is to try different looks, and then take the one that is for the current case, the most appropriate.
Together, the two methods, however, the same team several products simultaneously work for you. In Scrum, you often feel that this does not work (as a Product Backlog is always based on just one product). However, one could indeed be a team on several product backlog at the same time to work. The order of execution (in a row, alternating each sprint, at the same time, etc.) will be given jointly by the team reached with the Product Owner (s) specified.
With KANBAN, the whole thing much easier: A blackboard always belongs to a workflow, rather than a product. It is therefore readily possible to use several products at the same time using the same workflow to drive. For better distinction, one could still take different cards, or you carry more than one line (one line per product). But otherwise, no further changes to the process necessary.
Where at first the comparison between Kanban and Scrum. Here are the results again in a table briefly summarized:
Scrum Kanban
Iterations with a fixed duration. Iterations are purely optional. Fixed length is not mandatory, also control event possible.
3 rolls firmly planned (Product Owner, Scrum Master and Team). Initial no prescribed roles.
Team selects a set of requirements for a sprint, and undertakes to implement this. None of iterations, therefore, no solid commitments necessary. But there is the possibility to introduce SLAs.
Velocity (work done per sprint) as the primary parameters for planning and improvement. Throughput as the primary parameter.
Product Backlog is (descending) sorted by business value. Prioritization optional.
Entries must be in the Product Backlog in a max. a sprint feasible. Scrum tasks on the board are <= 1 day. Requirements may be arbitrarily large.
No changes to the requirements during a sprint possible. New requirements will be the earliest with the next sprint planning. New requirements can in principle be brought at any time (if a slot is free).
A Scrum-table after each sprint will be reset. A Kanban board is continuously updated.
A Sprint Backlog (and thus also a Scrum-table) is always exactly one team. A Kanban table can have any teams to be divided.
Cross-functional teams required (and also necessary, as a Sprint Backlog only by one team is being processed). Cross-functional teams optional. Even more (special) teams per workflow possible.
If you look at this table so committed, then you can see quite well how Scrum and Kanban actually related: Kanban and Scrum are not mutually exclusive. Quite the contrary: Since every rule in Scrum is a special case of a rule is Kanban, Scrum is really nothing more than a special case of Kanban.
Scrum is one of (probably infinitely) many ways to make Kanban …
BFI
Loading ...