Scrum to Scrumban in 6 Steps + FREE Cheat Sheet
Вставка
- Опубліковано 17 чер 2024
- Here's your roadmap for the journey from Scrum to Scrumban. And remember to grab your FREE CHEAT SHEET!
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
www.developmentthatpays.com/c...
In 2009, Corey Ladas gave us Scrumban. He presented it - not as an alternative to Scrum and Kanban - but as a PATHWAY from Scrum to... something more "kanban-like".
In this episode, we'll walk that pathway: Six steps that take SCRUM and add layers of KANBAN and LEAN.
Along the way, we’ll step outside of the boundaries of Scrum... but you may be surprised at how we get before we “break out”. Which means that even if you have no plans to move from Scrum to Scrumban… this episode is a must-watch.
-------------------
126. Scrum to Scrumban in 6 Steps + FREE Cheat Sheet
#DevelopmentThatPays
Last time I introduced you to this man, Corey Ladas, and his invention, I guess you could call it that, Scrumban. If you missed that episode and you'd like to catch up, you can find a link to it over here. As I said in that episode, Corey didn't so much position Scrumban as a midway, halfway house between Scrum and Kanban, rather as a pathway from Scrum to ... well, to something else. This I think was a super shrewd move, given the level of adoption of Scrum, and the fact that Scrum is often the first step that teams take when getting in to Agile. So how easy is it to follow this pathway from Scrum to Scrumban Well, I think we should go and find out. And as we travel, keep your eyes open for the moment that we break, or breakout, of Scrum. I think you might be surprised at just how far we get before we do so. Step one, visualize the work. Oh, you thought this journey was going to be difficult If you're like most Scrum teams, you probably already have a board. And the board is just one of the things that Scrum doesn't mandate. In Kanban though, a board is mandatory. It's one of the key tenants of Kanban that we must visualize our work. So if you have a board, even one as simple as this one, then you've already taken your first step toward Scrumban. Congratulations. At this point I'd like to introduce you to the team we're going to be working with today. I'm going to ask them to take themselves off for a super quick sprint planning session. And I do mean super quick. Thank you very much, team. Eight items, let's call them tickets, in the to do column. As this is Scrum, we could also call the to do column the Sprint Backlog, they're effectively one and the same. Time to set to work starting each day, of course, with a daily standup. One thing that every developer knows, but few will admit, is that it's much easier to start a job than to finish it. So if we check in with this team again after a couple of days, there's every chance that their board will look like this. And this where visualize the work starts to pay us back. It's very clear that the three developers are attempting to work on eight tickets simultaneously. I could spend a whole video, a whole series of videos, talking about why this is undesirable state of affairs, starting with the cost of context switching. But for now, I think we'll just move on quietly to step two. Step two, impose work in progress limits. If you know anything at all about Kanban, you'll know that one of the things it does is to impose work in progress limits. So let's give that a go. I'm going to rewind to the beginning, and this time each developer is allowed to work on a maximum of two tickets at any one time. Ideally, it would be just one ticket, but we know that things happen, and tickets can get blocked. So, we're going to give people just a little bit off leeway. So two tickets maximum. Let's see how that plays out. Fast forward a couple of days, and oh, it does seem now that we have all three developers working on exactly two tickets, we've given them the opportunity to work on two, and they haven't been slow to take us up on our offer. They've stayed within the letter of the law, but the spirit of the law, not so much. I think we should try a different work in progress limit, something a little more Kanban style. And I'm going to do that, not by applying a limit to a person, but by applying a limit to the process. The process here is the in progress column, and I'm going to squish it so there's only room for one ticket in the column. And I'm going to draw a hard limit at five tickets. It's hard to overstate the impact of what that simple change will hav
• Scrum to Scrumban in 6... - Навчання та стиль
Remember to grab you FREE Scrumban Cheat Sheet: www.developmentthatpays.com/cheatsheets/scrum-to-scrumban
Extremely well-done and very informative! I really enjoyed how you walked through the different steps and evolution of the board to arrive at the final outcome. It did a great job of highlighting the need for each component in the system.
2021 and i'm just looking into this now. This is a brilliant video which explains Scrumban and is very easy to follow. Well done and thank you for putting this toegther. One thing I would say as a recommendation which would really help is chapters so we can skip to sections we would like but I suppose UA-cam didn't have those when this was put out.
One thing i would like to mention in this is there is no talk about The 3 Buckets Planning (Long-term Prioritization) which is something other papers talk about. Just thought I would point that out.
Thank you for the videos and cheat sheets. An excellent primer on scrumban that's made a number of areas clearer and given me ideas to implement.
I used to work on various IT positions and now I am doing my best to become a Project Manager in Agile Software Development. This channel is so valuable, thank you so much for all the videos you made so far. I think you seriously deserve a wider audience. I haven't found anything even partially so great as it is, so my tour of watching all of your shourt courses has just begun.
@Michał - What a lovely comment! Thank you!
The best video ever created on Kanban and Scrum. So well explain and in such a useful way.
Delighted that you liked it. This video was the "surprise hit" of last year.
A couple things that I think are hard to overstate are:
- The customer is the ultimate source of pull.
- WIP limits are not only to protect content switching but the process/system; probably covered elsewhere but it's important as there are real reasons why limiting WIP can speed up the overall processing time - as well as help expose places where the current process may be stalling.
Awesome comment. Makes me want to stop what I'm doing, take your points... and make a video out of them!
Nicely done video and great atmosphere. Very helpful
Brillant sir! Hybrids IMO have always been the way to go, whether you work for the largest corporation or a new/startup company. If you bind yourself into what is not flexible, then you are simply just binded!
I'm using this method for a website redesign project with a crazy short timeline. We needed a system that would not impair progress by getting everyone to follow a complicated system. We not only have to design and program a website in a short period of time, but we also have to build a new client relationship including learning about their product. Wonderful explanations as always.
Great stuff!
Brilliant explanation and summary Gary...as always. 😁
Very informative video. Thank you so much for sharing your knowledge. Have a great weekend. 👍
Another outstanding video! Well done, Gary!
Chris - Glad you liked it!
Great video thanks for sharing. The "triggering planning" is definitely a game changer.
Glad you liked it!
The best explanation on Scrumban that I have come across. Thank you!
Thank you!
All of these videos are very helpful. Fantastic work, thank you!
Maurice - that's awesome. Thank you so much for your comment. 👍
Great video! I moved my two development teams to Scrumban almost a year ago. They were working on a new cloud migration project, which required a lot of research and trial-and-pivoting. The team loved the more structured way of dealing with priorities (without breaking a sprint commitment) and swarming on bottlenecks. The feature manager loved it because he knew that newly discovered information would be worked quickly since we let him have input on the prioritization of the backlog. Although the rest of our project (about 13 teams) are still working Scrum, I've partnered with some other Scrum Masters to understand how Scrumban can work for their teams.
That's awesome! I'll be quoting you in the next episode 👍
Chan - Your comment - and a couple of other Scrumban success stories - inspired me a to start a Scrumban group on LinkedIn. Would be great to have you on board - your experience would be invaluable to the group. Hope to see you over there: www.linkedin.com/groups/8705950/
Great video! Love how friendly you make it all!!!
What a lovely comment. Thank you!
Best session yet! Thanks.
Very aligned with David J. Anderson's body of knowledge.
I wasn't familiar with David J. Anderson - thanks for pointing me in the right direction. 👍
Wow, this is great. The way you explain things is an art!
Thank you! You made my day!
This is essentially what we were doing in my team, but without knowing that someone had already attempted to describe and codify it. Thanks a lot Gary for putting a name on it and suggesting a short list of principles.
Really? That's awesome! Curious to know how you got to where you are. Did you start out doing Scrum?
Still blown away by the fact that you "discovered" Scrumban independently. Would be great to have you be part of a new Scrumban group I've just started on LinkedIn: www.linkedin.com/groups/8705950/
Your videos are very well done Gary. The content is great but also the presentation. Scrumban sounds great.
Really glad you're enjoying the videos. (Look out for more videos on Scrumban coming soon.)
Chief...You are a Guru. Very practical & useful knowledge..thanks for sharing your deep experience...
Very nice and interesting video and concept! Not only once I had the struggle to decide Scrum vs Kanban depending on the project's nature. In my last project I used Jira next-gen board which helped me and the team to "visualise" the work and status as you stated in your video. I actually applied then the Kanban wip limitation concept and as soon as we were in a certain "favorable" status, I/we pulled-in items from the backlog. How? I exchanged 1 daily standup with a 1hr "trigger" meeting and we got the new tasks in. Unfortunately in certain cases we had to remove some tasks from the SPRINT but just the ones which will not "destroy/traumatize" the SPRINT goal even though is not typical to modify the sprint scope but well... I wanted to allow the "remove" option as well as I pushed for this "add to scope"... it was an interesting experience and learning process for everybody... didn't know it looked a bit like the "SCRUMBAN" :-) ... Thanks for sharing!
Thank you sir, for uploading this video, very enlighting! A question though: you mention that forecasting is still possible without estimating within scrumban, but how do you do so?
Using Little's law you can forecast in Scrumban but it will always be an estimation. There is no other way but to estimate. The point being that Little's Law is a far more accurate way of doing it then other methods.
Very very clear video explaining scrumban.👍
Good video. On little thing: we don't usually size stories during sprint planning. This is done in grooming sessions. In sprint planning we only consider groomed PBIs which had already been sized and now estimate them in time and not story points. We're rather precise at this point. 2 weeks is a heartbeat after all.
Yes, you're quite right: sizing is a grooming/refinement activity.
Very helpful and insightful
Thanks for the video. I will implement it in my team.
It would also be great if there is a sharing about how you can imlement it on technologies such as JIRA and Confluence.
Great food for thought again Gary, well done!
Couple of questions/remarks though:
1) Step 4; Ordering. This makes perfect sense but I wonder if you agree with me that technically this is already what you do in scrum. There should be order in your product backlog items (clear&important items at the top) so naturally when you start planning a sprint you keep this order as this is what the product owner (aka business visionary) deems the right order. This would also eliminate the need for the 'ready' column as items that are on the sprint board should be clear by definition (they are refined). In one of the teams I worked with we actually introduced a short 'definition of ready' for items on the product backlog to establish if they were ready to be discussed in the sprint planning. This speeded planning up a lot.
2) Step 5; Stop Estimating. Small remark here. In scrum you don't estimate during Sprint Planning, you estimate during refinement. Personally I've always thought of estimating as an indicator of whether you need more detail in your stories or not. If stories are given high estimates, chances are that they are not clear enough or can be split in multiple stories.
Glad you liked it!
Re. Ordering I. Think it's a question of granularity: it can be argued that Kanban is a special case of Scrum, where the Sprint Capacity is exactly 1 item. Yes, the Sprint Backlog is "the top of the list", but is there ordering WITHIN the Sprint Backlog? Usually not. (I'd also say that that's fine: the "granuality" is the Sprint... so sub-ordering is overkill.)
Re. Ordering II. Thank you for bringing up Definition of Ready. Sooo important.
Re. Refinement vs Sprint Planning. Arrrgh! What was I thinking?!? I want to re-record the whole video!!!
Re. Stop Estimating. Love this: "Personally I've always thought of estimating as an indicator of whether you need more detail in your stories or not."
I'm intrigued by this. Now I want to learn more about this.
I think I got it. Very nice video, thank you!
Maybe a 'newbie' perspective is worthwhile, maybe? I'm a 'newbie', but I'm 53 years of age. I've been at the 'where the feck is the thing I need' end of all this many times. Why am I interested? I've just discovered that 'innovation' is a 'job', a career and finally I have an inkling that the world of business may have a place for the natural traits that I have - critical thinking and ideation with the ability to be iterative, fast. Now, what I've previously thought of as 'bloody project managers' work becomes interesting to me now I know about 'Scrumban', because it has a place for 'me'. I am certainly on-board with this and await further news with great interest.... and an eye on a career change :-)
Amazing video, thank you!
My pleasure!
Another great video Gary and the use of WIP limits would help identify/solve a lot of sprint problems. I agree with Hesham that it would be difficult to remove estimating without finding an alternative to forecasting, especially if some of the work is outsourced to 3rd-party developers. I look forward to the next video.
Glad you liked the video. Agree that the "elephant in the room" is estimating/forecasting. I'm going to address this in the next episode.
Yep liked the video - esp the WIP limits. However I have and number of times come across when the 'in progress' hard limit has been hit and someone gets stuck .. so they move one of the tasks back into ready-for-development column and pick another one (Pick and Mix problem I call it)
Pick and Mix! Like it! (And yes, I've been guilty of it...)
Hi Gary, Another great video and it is indeed truly one of the hardest things out there in the "wild" to try and get teams to limit their WIP because their natural reaction always seems to be to get the next ticket out as soon as they start to slow down, which as you correctly state is not good for the team's capacity in the long run.
The bit where I do have a problem is the stopping of estimating... and its not necessarily the estimating bit that I disagree with the most. "Grooming" as we know its called in Scrum (I prefer to call it refining and estimating) is the most underrated ceremony of all but its actually crucial in the team's arsenal of dealing with the complexity and uncertainty (and therefore risk) that they face when it comes to actually delivering the stories they commit to. Its a fallacy that agile does not plan and in fact we plan all the time in Scrum - what we will do today in the stand-up and what we can do this sprint in sprint planning. But as I'm sure you know sprint planning is a painful meeting when the team haven't spent enough time refining (and estimating) the stories they are taking on. This is their chance to get a handle on what each story entails and the art of playing planning poker (during estimating bit) also helps to expose differences in thought, and therefore approach, that might not to otherwise be apparent.
I know I may sound like a bit of a killjoy here, but do you see where I'm coming from?
Not being a killjoy at all: I've long believed that the assigning Story Points is the LEAST valuable outcome of a grooming/refining. The PROCESS of getting to the point where a Story Point can be assign - THAT's where the magic is. Great comment.
Thanks for that. I forgot to mention in my original post that the omelette metaphor was a stroke of genius and I will be using that with my teams when coaching them on focus.
Ah yes. I wasn't sure about including the "restaurant scene"; wasn't sure that people would get it. Glad it worked for you 👍
Thanks, it does help !
Great Gary ! Thanks a lot
Rog - Thank you!
Thank you master. You had mixed even lean here....Very good..!!!
And you spotted it - I'm impressed!
great explanation
Excellent video Garry
Thank you - much appreciated!
The white big box is tilted, and this is killing me. Very good video :D
You're not the first to mention it! But what's really going on is the sloping roof.
Some things you may want to consider and/or address with this move to "Scrumban." You mentioned "arguably" that estimation is considered waste under Lean principles. Based on that and step 5, here were my thoughts:
1) Velocity can still be determined as it is based on the speed in which the work is done and doesn't necessarily need to be base lined by estimation.
2) Without estimation, all you really have is priority. That sounds great high level, but now you expose yourself to gridlock. Overall projects can get stalled when high priority/longer effort tasks consume a column thus blocking/gridlocking the board. Nothing new gets started while testing/releases are slowed to a trickle or halted altogether. If crashing a task will not speed the rate of completion, you've just broken all the advantages of having an agile team including the T-Shaped teams. This is a dangerous trap and easy to fall into.
It's not to say it can't be avoided but can you tell I'm uncomfortable with step 5?
@Geoff - I think your comment 👆was truncated. Could you try again.
Hi Gary, as noted in my previous post, I value Scrumban more than Scrum because it trigs corrective actions when needed while Scrum has periodic planning meetings.
So I asked myself if Scrumban was also better than Kanban.
I would again appreciate to have your opinion on the statements I formulated:
1) Even if introduced as a Scrum evolution, Scrumban is actually a special version of Kanban including buffer columns.
2) Agile promotes team members on the job skills learning and aim to multidisciplinary teams. Still it’s difficult to avoid sub-teams in the team what may be even a matter of fact when the team starts. Note that a sub-team can even be one team member with very dedicated skills.
3) Kanban requests a “multidisciplinary” team where all team members must have all the skills because team members are requested to switch between any item types depending on WIP limitations.
4) Scrum is suited to a “cross-functional” team where all skills are present but possibly from different team members because the sprint-planning activity foresee to load each team member properly by items selection and early-binding.
5) Scrumban is also suited to cross-functional teams. Not all team members need to master all skills because they can work in sub teams isolated by buffers as advised by the Theory Of Constrains.
6) I then value Scrumban more than Kanban because it is more tolerant with the team skills mix.
Thanks
Great episode.
First 4 steps are how I prefer to implement Scrum. I'm very hesitant to drop estimates as they're not done just for the sake of measuring velocity and forecasting but also as a prioritization tool. I hope you can address this point in the next episode.
Reading your comment warmed by soul. I was hoping that someone would say they had applied one or two of the steps - but I never dreamed anyone would have applied four. My feeling is that what you've done is rare, some I'm curious to know what led you down this path. Tell me everything!
velocity tends not be something most teams are interested in - it gives them nothing and does not improve the product. The forecasting though can be done externally to the process by measuring when a task of type x/y/z pops into the product backlog and pops out in production. Velocity can be useful ... but often gets abused by non-team members due to a lack of understanding since they assume all teams are relatively the same, For example team omega is getting through 1000 points per sprint whilst those slackers in team latrine are only doing 10, Omega are a data entry team and Latrine are infrastructure security.
100% agree. I'm living through (pretty much all of this) in my current role. I'll reveal all... someday.
Regarding the abuse of story points. I blogged exactly about this topic a while ago: blog.heshamamin.com/2017/02/abuse-of-story-points.html
I believe that proper education can solve the issues related to the abuse of story points.
Sorry for the late reply.
Nothing really impressive. I used various visualization methods according to different situations. Burn up charts, dashboards to visualize open issues, tech debt, etc.
WIP limit was a bit challenging in one environment I worked in where traditional PMs focused more on "worker" utilization rather than getting "work" done. IMO, if the team focuses more on work, a good enough utilization will be achieved as a side effect. The other way around doesn't work that good.
Prioritization is a continuous game the team should be working on. In very rare situations we assigned tasks directly to developers in sprint planning. The cross-skill task (Dev vs UX) is probably the most challenging.
Thank you so much
No problem!
Nice explanation! Thanks! I believe the teams have to be a bit mature in their execution of SCRUM, besides being generalist teams (something I do not have) in order for the suggested transformation to happen. Also I agree with the comments about retaining retrospectives, maybe a trigger is needed for these?
Pablo - Yes, others have struck a similar note of caution. Having seen a team go straight from Scrum to Kanban - and make a complete mess of it - I can't disagree.
Good point on Retros; it's not obvious that there's a natural trigger for this in Scrumban.
We use Scrumban in the way that we make use of Kanban and all the rituals of Scrum except the Sprint and the Sprintplanning. Instead we do a refinement session to make sure that a Kanban card is understood by the team and helds a DoD and DoR and is a small piece of work. So in the refinement session we also give points to these workitems, to be shure that all workitems are about the same 'size'. Every two weeks we do a review and every four weeks we do a retrospective. This all makes it possible to make our DevOps teams work agile.
Sounds good to me.
Dominica Degrandis brilliantly showed how to forecast w/ kanban in numerous talks
Thank you, I'll check her out.
I really like the way you have demonstrated the flow here and I’m very new to Scrumban as a concept so thank you very much for the video...I have a question that I hope you can answer;
If an item fails the testing stage, where does it go? If it goes back into the to do area, then it will have lost its priority, but if it goes straight back into development, what gets dropped? It would be great to get your feedback on this, thank you
IMHO it should normally stay where it is while its fixed. Testing stage doesn't mean only testers can work on it.
I don't like to think of it as "failing" the testing stage - it just needs some dev work to help it get through testing.
I'll have to check your future episodes to see, I like to take a few things from what you said especially the splitting up of the work and WIP limits, but the forecasting is what I want to look for. In addition, the methodologies like scrum etc do not lend well to retroactively looking into previous technical debt or low hanging fruits without much ceremony which I want to avoid for developers with initiative.
fantastic video
DELIGHTED that you liked it!
big thnx 4 video!
You are most welcome!
Thank you Sir for the great explanation. I'd add that there are no predefined roles in Scrumban- the team retains their current roles. One last thing, may I ask what software are you using to make this video.
Thank you.
What you've described sounds much more like Scrum.
You could make a rule that you are only allowed to use estimating, if you have made a project that is so similar, that you can build on it like or reuse.
I still think there's value in stuff like planning poker. It's less about the estimation and more about making sure the team is in agreement with regards to the complexity of the work. Also there needs to be some sort of check in place to make sure nothing too big is introduced to the board otherwise it could be on there for a long time. When someone points it as a 2 and the other an 8 this highly suggests more questions need to be raised before its ready to pick up.
Agree 100%.
This is a very quick overview so it's to be expected, but there's a bit of an issue at 17:04. The Ready To Test column is introduced, but it has no WIP limit, so in principle (and maybe in practice) a large backlog of untested work could build up there, which could be quite harmful. I think really it needs to share a WIP limit with the previous column.
Hard to do that visually if they're separate columns, but can be done as a numerical limit - or if we wanted to keep it a visual space based limit they could be kept as a single column and devs would just put a mark on tickets that are ready to test, or have a movable divider inside the column to mark a section that is the things that are ready to test.
Ready to test could have its own WIP limit, but WIP limits should be about restricting starting new tasks. Simply declaring something ready isn't really much of a task, and it doesn't make much sense to separate out the job of developing some feature from declaring it ready to test. If you hold off doing that just because of a WIP limit and then do it later when some stuff has been pulled into the test column you might forget details of whether the dev work is all done or not.
Hi Gary. I think this is awesome. Yet without the ability to timebox or estimate you have wiped out the ability to budget projects. Suggest that this be used on someone else's budget and not my own. My experience is that KanBan rolls on down the highway and along with the time that moves along are also the milestones and deadlines until the team is ... dead. Possibly you can convince me in later video's.
We've had agile\scrum rammed down our throats so I'm trying to understand it better. It has been difficult since I mostly do backend work, there are no customers though there may be a project owner yet, I'm still the only one that knows what the software is supposed to do. Releases are something like after 6 months... there is nothing to see before that.
You clarify one thing. I tend to specialize in techniques that no one else uses... ie. very advanced AJAX. People love what I make, web apps that behave like Windows apps, but you need unusual javascript skills to manage the DOM like I do. I've met very few developers that can do that and it's hard to learn. In a broader sense though, if you don't use a technology, you can't retain it so teaching it to the other team members would be useless.
I do see one thing I like about agile. It's horribly inefficient. It will give me time to burn even above the wasted time of meetings. I can say anything I want about time utilization because no one will have a clue what is required to do what I am doing. Cool.
I like this one.
Great video, I wish I'd seen this earlier. One question I have is when the estimation process is eliminated, what is the process for ensuring that development and QA understand the requirements and acceptance criteria? Is that during Triggered Planning?
That would be one place where it could happen. I'm also a big fan of the Three Amigos approach (which can be applied to just about any Agile approach). The trigger here is the work is picked up.
What a channel.
Thank you!
Hi, did you ever publish a follow-up video on planning and forecasting?
It's a coincidence that you should ask this question today: I just posted asking if anyone would be interested in learning more about *estimating* (a close cousin of planning and forecasting).
The short answer to your question is "no". But it looks like that might change in the near future. _Stay tuned!_
This very much mirrors what we just did with our teams (no small credit to your videos). The catch is that we're a service organization not developers. We kept a streamlined version of estimation points only for ease in retrospectives in isolating areas that need process improvement. If the task is weighty or there is a big difference between estimated time and actual time, it comes under consideration in the retrospective for scrutiny for process streamlining. In the first two weeks teams tried to keep to early binding and the sprint schedule. By week three they gave up, started focusing on unblocking review work (triggered by a new WIP limit) and started shoving work out the door like there was no tomorrow. We're five weeks into a fairly Scrumbanish Kanban and no one wants to go back. Our biggest issue is layering in important but not urgent tasks in the kanban prioritization so I keep hoping you'll tackle merging the Eisenhower Box topic with Scrumban. Maybe? Please?
THIS IS AWESOME!!! I don't know if you realise the importance of what you said at the end: "Our biggest issue is layering in important but not urgent tasks in the kanban prioritization". Corey Ladas said that a side-effect of Scrumban is that it pushes the power (responsibility?) back to the Product Owner... and back on to the important questions, like "Should be do X or Y.?"
Agree that this would be a good subject for a future video: it's on the list!
In our case we are delivering an ongoing service not developing a product so our "dev teams" are also the "product owner". The issue mostly comes in balancing implementation work (client work) which always feels urgent and process improvement work which is vital but rarely feels urgent. Btw, your boat analogy in a prior video felt spot on in this regard.
@Pinecone - Delighted that you liked the boat analogy: one of my favourites.
I need you!!! Your comment (and similar comments from others) inspired me a to start a Scrumban group on LinkedIn. Your recent experience would be super-valuable to the group. Would be great to have you on board: www.linkedin.com/groups/8705950/
Great videos , could you direct me to the right board . I have a plumbing and heating business and struggled with my customer service flow ( from the customer call for a job to actually doing the customer job ) thanks 🙏
I think I need to wait for your next video to get some of my questions answered. However, will be good to know:-
1) How do you time-box your sprint when you don't do sprint planning in Scrumban?
2) Estimation.. what about that?
3) Is there a concept of Velocity in Scrumban? How do you calculate them?
4) How do you track your burndowns?
Thanks Gary for this wonderful video.
Great questions:
1) You don't. The work - or lack of it! - triggers each planning session.
2) Just *don't* do it.
3) There's no concept of velocity; velocity is (usually) *Story Points* per *Sprint*... and we don't have either in Scrumban (nor in Kanban).
4) There's no burndown.
Feels like a lot is lost, doesn't it? Can you see what is gained?
I'm already doing some kind of Scrumban with my team. I started by not doing sprints anymore and estimate using ticket count. We became quite demanding about ticket splitting, I try to break down more complex stories into many smaller ones and, his way, we kept some king do predictabilty.
After migrate to this approach, I missed planning poker and estimation! When we (the team) estimate some task, we are encouraged to think deeper about the problem.
Also, if the team member is working on a task and get any unpredictable problem, we avoid spending extra time: if a task is estimated to, for instance, 3 points, we shouldn't take much more effort than other 3 points tasks.
Anyway, with or without estimation, this approach fits very well with continous delivery and, for me, seems to better use the manager time.
Well, as you said, we still have Sprint planning, Review and Retro. So not all is lost. However, estimation is important for some/most of the projects where you need to forecast project end date in Sprints. But you said don't do estimation. 1) Does this mean Scrumban is not for those team where you need to forecast work beforehand? 2) If there's no burndown, how do you track teams performance over a period to see if work can be completed in stipulated time? 3) How do you manage Project cost if you don't do estimation?. Thanks.
Fixed length and consistent duration sprints is a key characteristic of Scrum. A "just in time" sprint planning event defeats the point of the Scrum time box. I'm not arguing that it's not valuable, I'm just saying that when you depart from the fixed length time box (sprint), you've broken Scrum.
Re: Velocity - You could argue that the number of work items completed per week, month, quarter is a team's velocity. Though traditionally measured in story points, it doesn't have to be.
Chris Palmisano - Agree with you 100% on both points:
1. When we drop Sprints, we're no no longer doing Scrum. (I hope that was clear in the video.)
2. It is possible to swap (if that's the right word) Story Points per Sprint for Tickets per week (or month or quarter) I'll definitely be covering this in a future video.
Your videos are very helpful. One thing I've been trying to understand is how does one estimate cost of a project when it required by business for budgeting?
That's both easy and hard. Easy, because most of the cost of software development is the people, and it's easy to know how much you are spending on people (say) per month. That's the macro cost. Things get much harder for granular things, such as "how much will this feature cost?". Because that leads to questions like "How long will it take?" And that's a hard question to answer.
My question is in Scrumban when do we carryout the retrosteptive?
When that boot came in a lobbed the task from Dev to Test. lol
Gary: "We'd be wise to retain review & retrospective...and can still forecast."
Me: "Go on ...."
Gary: "You'll need to wait until next video."
Me: *ffs* [I wanted to condemn your argument because change is always bad]
Yes... I did side-step that one somewhat 😂
Does Lean recognize value added with Review and Retrospective? What is that value? Seems once that question is answered then review and retrospective will fit into the process again?
There's definitely value in Review/Retrospective: they are the enablers of improvement. (Think: Kaizen)
Forecasting though is not really part of the core agile process - but important important in its own right when analyzed with how long epics/stories/tasks take to do. Its harder in Kanban since you tend not to estimate things and there is an assumption that task size are all of the same size.
Retrospectives are useful and should be retained (but more add-hoc than every 2 weeks)- but you need to manage them and keep them focused on process improvement and actually action on them otherwise it turns into a developer bitching session which is not very constructive.
Hi Gary, I’m working in non-IT waterfall flow but get lately great interest in Agile frameworks.
I was also wandering if the Scrumban buffers should have a WIP limit.
I would appreciate to have your opinion on the statements I formulated:
1) Like in Kanban and unlike Scrum, Scrumban does not use time-boxing to limit the WIP. So all Scrumban process steps must have WIP limits to get the Just In Time property. This includes buffering steps.
In practice, this theoretical point may give the following:
2) Scrumban Ready column is useless: the ToDo column can as well do the buffering job while being repopulated provided that the planning meeting is triggered by the wanted buffering level (before ToDo is empty). Also, as Scrumban backlog, the ToDo column is already ordered. Scrumban ToDo is then the input buffer of the first execution process step (e.g. the Dev column).
3) In Scrumban, too low or too high items count in the buffers are warnings to trigger corrective actions. The low threshold trigs the Planning meeting for the first buffer (the ToDo) and allocation corrective actions for the other buffers. The High threshold trigs allocation corrective actions. The allocation corrective actions are exceptional in case the team and the WIP limits are correctly set.
4) The Scrumban buffer’s high level waring is best implemented by the detection of completed items stuck in the preceding execution process step because a WIP limit is defined on its outcome buffer. This also generates the allocation corrective action: the activity in the execution step will decrease due to its own WIP limit and the presence of completed items.
5) In contradiction with Just In Time principle, one can consider to suppress the WIP limit on the output buffer of the Constrain process step: unlimited offload capability is wanted there according to the Theory Of Constrains.
6) The Scrumban buffer’s low level waring is best implemented by the detection of empty buffer while the preceding execution column has WIP limit increased by the wanted low buffer amount. The extra execution slots are normally kept occupied by latest completed items unless the outcome buffer gets empty. When the buffer is empty a completed item is moved from the execution column to the buffer. This generates the allocation corrective action: the activity in the execution process step will increase due to its own WIP limit and the absence of completed items.
7) I value Scrumban more than Scrum because it trigs corrective actions when needed while Scrum has periodic planning meetings. Corrective actions arrive as late as possible (Agile) and are reduced to the minimal needed effort (Lean).
Thanks
Sorry for the late response. I was stuck on the issue of whether buffers should have WIP limits. My thinking went something like this: the buffer is there to "unblock" the system; but if the buffer is limited, then ... the system will block again.
My thinking was flawed. The buffer should indeed have a limit. This means that the system will block. AND THAT'S OKAY.
And I'll go one further and suggest a value for the buffer limit: One.
To your points:
1) Okay
2) If both columns really do the same things, then one is a waste.
3) If buffers are there, they are there to be used. They are necessary for flow, and are not (necessarily) danger signs.
4) Think this statement might be unnecessary: it describes "states" that arise naturally from other points/principles?
5) Not sure I understand this point. Can you say more?
6) See 4)
7) Think this mixes two things: corrective actions are - or can be - every bit as "continuous" in the Scrum as in Kanban... because there's no reason not to employ Kanban (via a multi-step buffered Kanban board) in Scrum. A more fundamental distinction between Scrum and Scrumban is at the Planning stage (where Scrum introduces at least two kinds of waste).
Great video thanks so much, i'm about to start an internship at a big company where they have just moved from Scrum to Scrumban. How do Sprint Goals fit into this please?
Congratulations on your new role!
On Sprint Goals, it depends how far the company has moved along "the Scrumban path". If there are still Sprints, then Sprint Goals can be applied. If not...
Nice Video very informative and practical for me a new Scrum Master :) I wanted to ask one thing: If the testing is finished, and there was BUG found, how should we work then? Move it back to ready for development or to development? Development can be full sometimes I think. Would be nice to hear your opinion, what do you think about it? :)
Bugs found in test should be addressed immediately! I mean walk over to the developer, pull off his headphones, shout in his face. Kidding. But the "immediately" party is important: three team works together to move work across the board, and that includes Dev and Test working together to resolve bugs.
A great video...
Thank you!
Although it was true at the time this video was published, I don't believe estimations are a part of the Scrum guide anymore. So it fits even better today than it used to.
Awesome explanation about Scrumban.
I still have a question, my team usually using Scrum and now we're moving to Scrumban. We usually using sprint as well, in Scrumban do we still use Sprint? In each Sprint we change our board to a new one, do we have to change our board to after planning in Scrumban?
Great question. The answer depends on how many (Scrumban) steps you take. In the initial steps (all of which are beneficial) you continue to work in Sprints.
Short order cooks work on many different orders based on the grill size for speed and efficiency. The orders are standard with not in development.
You're right! And the grill size is key. My guess - I'm no expert in this (kitchen) area - is that such parallel working is applied in such a way that the "cycle time" for an individual item is not impacted. Is that the case?
@Gary and all here did i miss it or does the video on still need to be created? Great content by the way.
For estimation i stuck with having the dev's create workitems sized 4 hours or less based on the stories to help guesstimate when stuff should roughly be done. Anyone else doing it different / better?
Sorry, Remi: is there a word missing from your question?
Re. estimation (or the removal of it!) - keeping the tickets small is a very good start.
One doubt here. How did we lose the concept of sprint here? The board that is displayed in the video represents one sprint right? Or is it the entire scrum?
For Buffer also WIP limit has to be applied else there will be a lot of items waiting which are half finished is a waste in the system as well. Let me know your thoughts
To be honest, that's the one thing I'm not sure about. I agree that there should not be too much in the buffer... but if it's full, it blocks the entire system. The buffer is like a fuse - a safety value - for the system.
As I said, I'm far from certain on this point.
@@Developmentthatpays IMHO the buffer should share the wip limit of the previous column. Buffered work isn't actually "in progress", it's waiting, so it isn't really possible to apply a WIP limit to it.
when you were explaining 'visualize the work' in this video, you showed few cards with some 'numbers' on them. whar are those numbers, if they are not story points - because later in session you suggest not to estimate - which means no story points. so what are those numbers there? and also the threshold that you are suggesting, is that just based on the number of stories? or there is a size factor also under consideration?
The numbers are Story Points. What I'm describing is a step by step process - and "stop estimating" is a later step.
As for the threshold, that's pure Story count. (Or ticket count, if you prefer.) There's no consideration of the size of each ticket.
Great questions. Thank for taking the time to post them.
Hi Everyone, can we do the sprint review event in scrumban frame work? Please put your suggestion.
How do we limit WIP without sizing (estimating) the tasks? How do we prevent bringing in a single task that busts the WIP because it's too large or complex?
Great, great question. The unit of measure of WIP is task count. If the WIP limit is two, that means that means two *tasks* - regardless of their size.
That's not to say that tasks that are too large (or complex) are not an issue: one of the "skills" in a kanban/scrumban is to split Stories to (hopefully) ensure that each task is "small".
Keen to try this out. One question about the WIP limits - what would you do with tickets which are blocked from an external team you don't have control over? So for example if the development team has completed all work they can on their tickets but then a different team needs to set up the coinciding infrastructure and can't do that for 2 weeks - meaning the tickets cannot progress to test and done - what then? I currently have a blocked column but feel like this would take away from the whole point of only X amount of WIP at one time. Hope this makes sense, thanks!
I'd love a good solution on this as well. Our issue is items blocked by clients. We're experimenting with a column that represents this status so we can visualize and prioritize how to tackle it, but haven't been brave enough to put a WIP limit on it.
Great question: as you said, not all tickets are "unblockable" by the team. In that case, I think we have no choice to remove it (temporarily) from the "column". This will unblock the pull system (good thing)... at the price of slightly increased WIP (bad thing).
Bonus tip: a dedicated column for "Blocked" items isn't ideal, because it loses information; I want to be able to see at a glance a what stage/process the ticket became blocked (design/dev/test/etc). On a physical board, I'd do it with a "Blocked" *row* at the bottom of the board. On a electronic board, flagging/tagging the ticket is an option.
@Marion - Great stuff: important to keep the blocked items front and centre.
gracia papi
Gary, is that shelf level, the upper right one as I look at it?
Think so. I'll check next time I'm down there.
@@Developmentthatpays It most definitely was not at the time of the video, but the content was so good that I managed to suffer the asymmetry to the very end ;).
hi! I just have a doubt that may be dumb, sorry if it is. What happens if, say, one or more of the "cards" get to the Test area but gets somehow rejected by QA or is considered to require some kind of fix? Does it go back to Dev or Ready to Test? Or does it go back to the To Do list? How does that affect the whole process?
Outstanding question! (I must do a video on the subject.)
A Scrum Master of mine taught me a valuable on this: he had an eagle eye for cards moving left on the board (i.e., indicating that a bug had been found). He wanted the bug fixed, and he wanted it fixed NOW! He saw the bug as disrupting the system... and by AMPLIFYING the disruption, he taught us to avoid bugs in the future.
To answer your question: I guess the Dev and QA can decide whether the card stays put (quick fix) or moves back to Dev. But it shouldn't move back to To Do.
Hi, I am still not understanding how it that there is no sizing? Not even when we set the case as READY? When we size we set the level of complexity of the case, and in case of an EPIC or big user story we split the case on many cases of less size to lower the complexity on the case.
If we do not size then an EPIC case could be added as one work item. So one developer working with hughe peace of code to be sent to another tester afterwards to test a huge peace of code which all the invonveniences this brings. So I think that at some point, at least when we set the item to READY some form of evaluation or sizing should be done anyway...if not as I said how can we avoid to have EPIC or big user story mixed among smaller ones..?
One of the big sticky points on my current scrum team is user stories. In Kanban, do you still need them? If not, what do you use?
'fraid so. Can you say more about why User Stories have become a source of pain?
Yes stories are important since they define what the goal of the story is and what the acceptance criteria are. That said you may not need to keep to the old rigid syntax such as 'as a fighter pilot i need the jet to drop bombs when I press the bomb release button so I can crush my enemies'. Those kind of stories generally tend to work well for UI related tasks rather than back-end or technical debt stories (think investigation as to database/tech to use/audit etc),
I just started coaching them, but I have a feeling it is the way they were taught to write the stories. So changing the behavior is a struggle.
Srumban sounds like a great idea. However, I'm still a little skeptical of the step where you eliminated estimating. Is it really fair to say that estimating adds no value at all?
There are two primary reasons to estimate: long range (forecasting), and short range (to select a "sprint's worth" of work).
For forecasting, it has been shown that forecasts based on raw Story count are more accurate that those based on estimates.
As for selecting Stories for a Sprint; there _may_ a role for estimating. (Of course, Scrumban drops Sprints as well as estimates.)
As well as the primary aim of estimates, there are some "side effects". Most are negative, such as estimates that somehow becoming _commitments_. At least one (side effect) is positive: the discussion required to arrive at an estimate can be extremely valuable to the team (to help the team to understand the requirements, examine alternatives for implementation, etc).
On this last point, there's another basis for discussion - Story Slicing - that yields superior results.
Adding things up, that's a small positive and a whole list of negatives.
How does the work of the user experience designer fit into Scrumban?
Scrum doesn’t mandate estimates… sprint planning mandates 1) why the sprint is valuable 2) what can be done to meet this 3) how it will be done. No estimates need to be given
You're right!
Now just understand that somehow I used Scrumban in many ways without noticing
❤️
❤
I have the only question about User Stories that are huge and need to be decomposed.
How to deal with it?
That's the art and science (!) of Story Slicing. This episode goes in to more detail: ua-cam.com/video/K6PqofeqoCc/v-deo.html
Well I guess Gary is now my ultimate Agile superhero
I'll need a cape! 🚀
How do I track burndown, velocity, etc. How do I handle Epics? What tools are there that support Scrumban? And most of all... how can I have predictability (towards stakeholders) as there is no clear sprint planning?
You can't track burndown, velocity, etc... but that's not unique to Scrumban: it's the same situation for Kanban. The predictably (towards stakeholders) situation is better: Scrumban retains (sprint) planning... although it's no longer "every two weeks".
everything up to 11:21 seemed like traditional scrum to me.. am I correct?
Yes... although I'll state it differently: everything up to 11:21 falls within the scrum framework. I make the distinction, because only a small proportion of scrum teams will implement scrum in this way (i.e., applying the principles detailed before 11:21).
When we dont have estimation and sprint limited time who to answer when it comes to the management and stockholders question when you will finish this tickets ?
Hi, you can use the average cycle time, throughput, Itema age and WIP limits. However, the usage of forecasts using SLEs is strongly suggested. It is based on the historical Cycle time of the team and it is a pretty objective way of "measuring".
SLE? Same/ similar to SLA (service level agreement)?
It's a good idea to assume that any ONE ticket - however straightforward - has a high chance of NOT being delivered. So we should - as a team - only commit to "bigger things" (e.g., epics) that can be delivered EVEN IF without one or more of its constituent tickets.
Chef sees another ticket... looks at stove top and its rush hour and every range is occupied... lol yes on a surface level this analogy works but a chef definitely got multiple dishes running at a single moment.
His WIP is infinite or else it's his ass lol