+Heidi Manning Typically we wouldn't look at velocity - that's typically used to calculate how much work a team has done/can do in a sprint (timebox). We don't normally use timeboxes in Scrumban (although you can - that's a little more involved), so we don't typically track velocity. We do track what's called "lead time" and "cycle time" which is the time required for the team to deliver work from when the work hits the backlog (lead time) or from when the team starts working on the item (cycle time) until it's delivered. I go a little more in-depth on that in my Transforming Teams to Kanban and Scrumban video. If you still want to use timeboxes for planning/executing your work, you'd continue to do what you do in Scrum - estimate the size of the work, focus on completing work and delivering value, and then finding out how much work the team was able to deliver in that timebox. But you'd do in a way that limits your work-in-progress (WIP) and focuses on completing work or pulling work through the system. Hope that helps answer your question. :)
It's not very clear to me when the retrospect is going to happen, I think that scrumban can work quite well on research and design projects, sometimes the discovery itself can be the whole project, but at the same time, is easy to see that such a project can take months and it'd be nice to still have the "cycle" to at least stop and seriously retrospect before spending one more month into things
My personal experience is to use a two-week cadence for retrospectives. It seems to be a "Goldilocks timebox" for retrospectives. We still have to do it - it's the instantiation of principle #12 in the Agile Manifesto - and a regular cadence is a good practice. Scrumban has a lot of practical uses beyond R&D. I use it for almost everything I do. If you need to do discovery around work you're going to be doing soon, use spikes. If the discovery about things you're not going to work on soon, why are you doing it? We want to maximize "the amount of work NOT done" (principle #10), so we don't want to do discovery too far in advance. Hope that helps! If you have any other questions, don't hesitate to reach out to me - artemis@artemisagile.com!
Hi, Thanks for this video. Can you give me some ideas on how you might come up with a team's velocity using scrumban?
+Heidi Manning Typically we wouldn't look at velocity - that's typically used to calculate how much work a team has done/can do in a sprint (timebox). We don't normally use timeboxes in Scrumban (although you can - that's a little more involved), so we don't typically track velocity. We do track what's called "lead time" and "cycle time" which is the time required for the team to deliver work from when the work hits the backlog (lead time) or from when the team starts working on the item (cycle time) until it's delivered. I go a little more in-depth on that in my Transforming Teams to Kanban and Scrumban video.
If you still want to use timeboxes for planning/executing your work, you'd continue to do what you do in Scrum - estimate the size of the work, focus on completing work and delivering value, and then finding out how much work the team was able to deliver in that timebox. But you'd do in a way that limits your work-in-progress (WIP) and focuses on completing work or pulling work through the system.
Hope that helps answer your question. :)
It's not very clear to me when the retrospect is going to happen, I think that scrumban can work quite well on research and design projects, sometimes the discovery itself can be the whole project, but at the same time, is easy to see that such a project can take months and it'd be nice to still have the "cycle" to at least stop and seriously retrospect before spending one more month into things
My personal experience is to use a two-week cadence for retrospectives. It seems to be a "Goldilocks timebox" for retrospectives. We still have to do it - it's the instantiation of principle #12 in the Agile Manifesto - and a regular cadence is a good practice.
Scrumban has a lot of practical uses beyond R&D. I use it for almost everything I do. If you need to do discovery around work you're going to be doing soon, use spikes. If the discovery about things you're not going to work on soon, why are you doing it? We want to maximize "the amount of work NOT done" (principle #10), so we don't want to do discovery too far in advance.
Hope that helps! If you have any other questions, don't hesitate to reach out to me - artemis@artemisagile.com!
Artemis Agile Consulting I agree with the two week cadence, one week week just means it's always rush hour and people get burned out.