From Scrum to Scrumban
Download as PPTX, PDF6 likes6,082 views
This document summarizes John Peltier's experience transitioning from Scrum to Scrumban for product development. Some key points: - Retrospectives revealed their team was taking on too many stories at once and planning was draining. - They adopted elements of Kanban like just-in-time planning and work-in-progress limits, while keeping Scrum elements like iterations, standups, and retrospectives. - This "Scrumban" approach resulted in a 20% increase in productivity and improved morale. It released more control to developers and relieved pressure on product managers serving as product owners.
![Product Management
To “identify an urgent and pervasive problem, and
determine people are willing to pay to solve it.”
[via Pragmatic Marketing]
Then, guide the design and delivery of a solution
for profit. (“product-market fit”) Ability to sell
influenced by, among many things:
Time of delivery
Depth of solution](https://image.slidesharecdn.com/fromscrumtoscrumban-120620214633-phpapp01/85/From-Scrum-to-Scrumban-3-320.jpg)
From Scrum to Scrumban
- 1. An Agile Journey John Peltier June 19, 2012
- 2. About Me John Peltier Product Manager – The Network, Inc. Lead Organizer – ProductCamp Atlanta Twitter: @johnpeltier Twitter: @pcampatl
- 3. Product Management To “identify an urgent and pervasive problem, and determine people are willing to pay to solve it.” [via Pragmatic Marketing] Then, guide the design and delivery of a solution for profit. (“product-market fit”) Ability to sell influenced by, among many things: Time of delivery Depth of solution
- 4. What is scrum? Scrum <> Scrumban http://www.flickr.com/photos/royskeane/413103429/
- 6. What is kanban? http://www.flickr.com/photos/blambar/5392387797/
- 7. What is Scrumban?* Elements from Scrum Iterations Standups Retrospectives Demos Elements from Kanban Just in Time Planning Work in Progress Limits http://pictofigo.com/download.php?id=250 *our team’s interpretation
- 9. Why We Transitioned Retrospectives revealed: Too many stories at a time Planning was draining Details forgotten Additional reading: http://www.scrumology.net/2011/01/26/dipping- your-toes-into-kanban/
- 10. Release Planning 1. Review Balsamiq Mockup of Release Candidate Shows happy path / primary features 2. Create user stories to reflect the vision 3. Size the stories (small / medium / large) 4. Prioritize the stories 5. Get to work http://pictofigo.com/download.php?id=1249
- 11. Why scrumban helps product managers (when serving in the product owner role) Credit: Mountain Goat Software and Rich Mironov
- 12. Outcomes 20% increase in velocity Tangible improvement in morale
- 13. Conclusions Scrumban releases control to dev Dev must “grok” the end goal for scrumban to work Relieves some of the forced ritual of scrum May relieve some of the pressure on overburdened product managers who are serving as product owners
Editor's Notes
- #2: How many project managers are in the room?
- #3: Comparison:Rituals in common: Retrospective, Demo, StandupsDifferences: Commit; Sprint Planning
- #5: For those of you who are not familiar with product management…KNOBThe interest in meeting deadlines is really backed by market pressures – market opportunity is often times limited by time.
- #6: Scrum is aniterative process of software development, characterized by a small team of people working together on individual tasks and then moving on to the next one.TIMEBOXIn scrum, work is broken up into “user stories” that compose the product backlogSome subset is estimated and brought into the individual sprint backlogThose are built and tested and made ready for productionThen the next subset is started in the following sprintThe number of “points” completed contributes to velocity.
- #7: Scrum ritualsSprint kickoffDaily standupSprint DemoRetrospective
- #8: Kanban is a pull-based system of managing work. The team works on an individual item to completion before taking on a new one. 2 keys:1) No iterations – the team simply burns through items in priority order.2) Planning of the story happens as the story is started, NOT at the beginning of the iteration.Kanban is characterized byExplicit work in progress limitsVisual workflow (frequently borrowed by scrum)Emphasis on “cycle time” to increase rate of flow
- #9: Retaining iterations provides structureBut still allowing for JIT elaboration upon stories
- #12: One of the big obvious questions…The team must already know the vision of what they’re going to build.Attention to story splitting: - leave them too large - or drill down by…….
- #13: In a commercial software organization, the product manager is juggling many things besides engineering.By conducting release planning and then getting to work, we have counteracted the product owner’s sporadic availability so that it is not an obstacle. Product owner is present 50% of time, always for standupsWhen the team is ready to start a new story, PO makes himself availableTeam takes responsibility for some analysis (particularly on technical stories)Scrumban doesn’t work if the team doesn’t know what it’s doing next!