Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
You can change this under Settings & Account at any time.
Introduction to Kanban
Transcript of Introduction to Kanban
Team's work cannot be interrupted during sprints
Team's work is time boxed (sprints)
Team has to have a daily scrum meeting where the team answers to 3 questions
Progress is measured using a burndown chart
Teams do a demo to stakeholders at the end of each sprint Kanban is more flexible Visualize workflow
Limit Work in Progress Visualizing the flow of work and making it visible is core to building an understanding how work works
The columns on the board representing the different states or steps in the workflow and the cards the feature/story/task/result of the workflow Visualize the workflow Pull system is implemented on parts or all of the workflow
The pull system ensures continuous, incremental and evolutionary changes to your system
The critical elements are that work-in-progress at each state in the workflow is limited and that new work is “pulled” into the new information discovery activity when there is available capacity within the local WIP limit. Limit WIP The flow of work through each state in the workflow should be monitored, measured and reported. By actively managing and monitoring the flow, changes to the system can be evaluated and positive or negative effects on the system can be identified. Manage Flow With an explicit understanding of how things work and how work is actually done it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions Make Process Policies Explicit Improve collaboratively The Kanban Method encourages small continuous, incremental and evolutionary changes that stick. When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus. KANBAN BOARD Goals Story ProcessSteps The big things we’re driving at that compel us to build software to achieve these goals. Keeping our product goals visible on the boardkeeps everyone on the same page — focused on achieving those goals It’s a queue because the stories are “standing in line” — the story at the top will be the first to be started. When started it’ll leave the queue and all the others will shift up. Story Queue The first column is often used for elaborating the story. If a story is here, the UI is being prototyped or describe sufficiently so that development can proceed. You might have a column where business analysts spend time tracking down technical details that developers need to understand to write code.
The next column is often used for development. And, the column after that for testing.
The team discuss the phases that stories go through to be completed. Consider using columns for writing documentation, or preparing customer service people to support the feature in production.
While it may be true that different people’s job titles focus on different columns, focus on the story and what it needs to mature. For example if your organization doesn’t use business analysts or user experience people, use the first column for the place in story elaboration where developers sit down and talk to business people and others to describe
Each process step column is divided into two parts: The top is used for stories currently in progress in that phase. The bottom is the buffer. The last process step won’t have a buffer — because when that phase is complete the story is done. When we set limits for work in progress, we’ll set a total number for the process step that includes both “in process” and the “finished buffer” for that process step.
When the story reaches the “done” row it’s ready, really ready to be deployed into production. Columns aren’t set Column names aren’t job titles Large goals for the product A list of prioritised stories
ready to be started When work for a phase (column) of the story is completed, it moves from “in progress” to the “buffer” where it’ll wait to be pulled into the next phase DONE - Stories must be minimal marketable features Set limits for work in progress This is usually determined by adding up all the members of the team in all roles and dividing by two. All roles includes developers, analysts, user interfaced designers, testers, deployment people — anyone immediately responsible for getting features to market. Secondly set limits for each column Firstly set overall WIP limit on the board. Limiting the items in the “stories” queue - set this limit at about half the total “in progress” limit
story process steps (analysis, development, qa and more) - the limit is often half the number of people that can perform the work for that phase of development
The total of all the limits for each “in progress” slot on the board, should add up to the total work in progress limit.
You may need to jiggle the limits in each process step to get them to work out right. Or, you could raise the work in progress limit — which is a little like printing more money when you run out. There are always urgent feature requests or issues in production that need immediate handling. Above the stories queue and each of the story process steps columns is an expedite slot. The row of expedite slots forms a “fast track” across the top of the Kanban board. It’ll be pulled from that slot, and moved through the story process steps as soon as possible, and ahead of all other work in progress. Expedite track When an item is placed in this fast track slot, it becomes the immediate highest priority for the team Cycle Time Measure story-by-story how long they took to complete — the “cycle time” of the story.
Record the entry date of the story (into story queue)
Record the start of WIP date
And finally, record the date when the story reaches the last “done” column at the end of the board.
The difference between the entry date and done date is the cycle time that includes the wait time in the queue.
To estimate cycle time for new stories, take the average cycle time from the stories completed. SCRUM a method for developing products
emphasis on just-in-time delivery
while not overloading the developers
emphasizes that developers pull work from a queue
process is displayed for participants to see - from definition of a task to its delivery to the customer You’d still find the “heartbeat” of regular cycles in a team using Kanban boards — at least if they’re doing agile right you should. The only difference is the cycles aren’t used to plan and commit to stories any longer Evaluation cycles, not development time-boxes Team synchronizes every day Reflect every few weeks Demonstrate every few weeks The daily standup or daily scrum meeting occurs as normal, but now it occurs in front of the Kanban board. Instead of the regular meeting ritual of checking in with each person to find out what they worked on yesterday and will work on today, the discussion revolves around the Kanban board and what will likely move on and off the board today, where “traffic” seems the heaviest, and what we could do to clear bottlenecks. summary of KanBaN process Every few weeks the team still holds a retrospective to look at the process they’re following, discuss successes and ways it could be improved. To show progress to stakeholders outside the team, a regular product demonstration is scheduled to show the product and get feedback from stakeholders.