I'm not a fan of measuring velocity. Velocity is a point-in-time measure of capacity. That means that when things change for the team or in the code, the velocity often changes. (See Velocity is Not Acceleration.)
Instead, I like to measure cycle time. Cycle time is the entire time it takes a team to finish something on their board.
Cycle time indicates how much the team collaborates together and how small the stories are. We want more collaboration and smaller stories in any agile approach. That's why measuring cycle time creates a virtuous (positive) feedback loop.
Collocated teams who collaborate on small stories tend to have short cycle times. Distributed teams who can't collaborate, even on small stories, tend to have longer cycle times.
Here's how to measure cycle time:
- I like to use a value stream map to see the wait times and work times.
- Note every time the work changes state: is it a work time (above the line) or a wait time (below the line)
- Add all the work times together.
- Add all the wait times together.
- Cycle time is all the work time plus all the wait time.
Now, you have data. If the work time is similar to the total time, the team moves as fast as it can. If the wait time is similar to the total time, the team is not collaborating as much as it could. They have handoffs and wait states.
BTW, it's often not the team's fault that they don't collaborate. That's often the case that the managers ask team members to do work that's not the team's work, or if the managers believe in resource efficiency.
Let's walk through two different teams, one that collaborates and one that doesn't.
Map the Value Stream for a Collaborative Team
This team collaborates, often in triads. Stephanie and Dan pair on the development. In parallel, Tim creates tests. While Tim can't finish his work until Stephanie and Dan are done, everyone is available to see and resolve a couple of problems once Tim runs the tests.
They do have to wait for Peter to be available to review the story. However, once they are all available, they mark the story as done. This story has a cycle time of 5.25 hours, of which only .5 hours is wait time.
Since the wait time is less than 10% of the total time, I wouldn't worry much about that much wait time. I might ask the team if that's okay, but I wouldn't stress until I had more data.
Before saying the team's average cycle time is 5.25 hours (originally a typo, now fixed), I would measure more stories. What is the team's average? Maybe this was a really fast story. Maybe the team more often takes 2 days to finish a story. One story doesn't offer enough information. What does matter is wait time for the various stories.
I like to measure cycle time for a week or two to see what the cycle times look like before I can use an average.
Map the Value Stream for a Team Where People Work as Individuals
This team works quite differently than the previous team. The people work as individuals.
Sam works alone and then asks for code review. It takes time for someone to be available. So, when Dan finds a problem, Sam asks Dan to keep an eye out for more problems. Then, Sam has to wait for a tester. Cindy is finally available 4 hours later. She finds problems with the code. The two of them clarify the intent of the story, so she changes her tests and Sam fixes his code.
Neither of them asks for more code/test review. That might not be okay. It depends on the team's working agreements about code or test review.
They then have to wait for the PO to become available to review the story.
Their team's cycle time is 18.25 hours. Look how much of that is wait time: 10 hours. More than the work time.
We don't know if the team thought this story was easy or difficult. But the wait time? That's very long.
The wait time for cycle time is why thinking in flow efficiency is so important. And, for thinking about how to collaborate as in pairing, swarming, or mobbing. Anything that keeps the team's WIP to one item will lessen the wait time in the team's cycle time.
Use Cycle Time to Estimate Story Duration
In Create Your Successful Agile Project, I recommend against velocity or using story points. Instead, I recommend teams measure and use their cycle time to see how long a story takes. (I also recommend you count stories. It doesn't matter what the points are. If your team always finishes two stories in an iteration, you have a cycle time of 5 days. You don't have to estimate anything. All you have to do is discuss the next two stories.)
Cycle time is real. You can count the stories, use your cycle time and generate a reasonable estimate. You could even run probabilistic scheduling to see what the most optimistic, realistic, and pessimistic dates are.
When I coach teams, I suggest that if they see a way to reduce cycle time, they should discuss that way anytime to see if they can reduce wait time.
See if you can measure cycle time instead of velocity. I'd like to know if cycle time works for you, too.
P.S. In response to a comment on this post, I wrote Thinking About “Beating” a Team’s Goal. Hope you enjoy it.
Update: This post is in Japanese: https://www.servantworks.co.jp/posts/measure-cycle-time-not-velocity/
Domo Arigato! (If I said that right.)
Either there are some typos here, or I’m being dense. I vote for #2, but my self-esteem insists I my questions as if it’s #1.
“Before saying the team’s average cycle time is 5.25 days, I would measure more stories.” — did you mean to say hours not days?
“Maybe the team more often takes 2 days to finish a story.” — does 5.25 hours translate to two days somehow?
“If your team always finishes two stories in an iteration, you have a cycle time of 5 days.” — I totally can’t figure out how the math works on that.
Chris, typo!! Yes. 5.25 days is supposed to be hours. I will fix that in the text.
In the para with “Maybe the team more often takes 2 days to finish a story.”: That’s just one story, the one that takes 5.25 hours (not days as you correctly pointed out.) However, you can’t just measure the cycle time for one story and know how long the average/median story takes. I was offering options, as in maybe 5.25 hours was a really fast story. Maybe the team more often takes two days for a story.
Lower down, I said: “If your team always finishes two stories in an iteration, you have a cycle time of 5 days.” Here’s I’m taking the total time the team works on a story. In one iteration, your team might finish one story in 3 days and another story in 7 days. Total of 2 stories. Average cycle time of 3+7 (10 days for both stories) divided by 2 stories = 5 days cycle time.
Maybe in the next iteration, the team finishes one story in 2 days, but 8 days for another story. Still cycle time of 5 days. The problem with such wide variance is that you lose the ability to create a better prediction. I would definitely use a Monte Carlo simulation (probabilistic scheduling) to see the worst cases. (I didn’t address how to do that here.)
I often see teams who manage to finish two stories. They have all kinds of reasons for doing so. They keep thinking they can do “more” because their velocity says so. But, they can only finish two stories. When they move to measuring their cycle time, they start to see why.
Thanks very much, Johanna. That clears up the math details. Still pondering how this helps the team focus correctly. Would tallying wait time do the same? It wouldn’t catch the problem of stories being too big, but should that be included in the same metric? Again, thanks for the fast response.
Chris, if you only look at the aggregate of wait time, you can’t see the wait states. Does the team have an available tester or UI person? Does anyone need to wait for someone outside the team for an answer? What about deployment? That’s why I suggested the team map the value stream. Yes, with a picture.
When the team sees their actual flow of work, they can decide if they like that flow or if they want to change how their work flows through their team. Velocity doesn’t discuss that at all, which is why I no longer recommend velocity as a measure.
When people see their flow and their wait states, they can ask more questions. I worked with an organization who had problems as in Unearthing Your Project Delays. The managers thought the teams were “lazy.” The managers could not believe how long things took. (Literally) Any given story was a small number of points. But the wait times overwhelmed the work time. (That article doesn’t have the value stream map as an image. I think you can visualize the wait times. If you would like me to show the value stream map, let me know. I’ll do another blog post so you and others can see the wait times.)
Actionable information is power. Visualizing the cycle time to see the flow, and calculating the wait times can help a team decide what to do next to improve.
(I can respond fast when I’m in my office as I am now. Thanks.)
Why not measure both? Measuring both will help isolate impediments (cycle time/lead time/takt time) and help encourage the team to improve estimation and scoping of work. “Beating the last goal” is a huge motivator for the teams I have worked with and Product Owners really like being able to have something tangible to forecast with (velocity). As long as doing both doesn’t add an impediment I would suggest two points of measure over one.
Shaun, I think I’m missing something. I’m not sure how “beating the last goal” in terms of velocity makes sense. (At least, to me.) I have these questions:
– Why is a set of stories or velocity a goal? (I might not understand what you mean here.) I understand a sprint goal, but I don’t happen to subscribe to it.
– If velocity is a goal, why not reduce cycle time? That would allow more stories, which is the point, not more story points.
– You can use cycle time (or counting stories) as a much better (more empirical and more grounded in reality to) forecast than velocity.
(I feel another blog post coming on :-). You raise interesting issues about how a team can create a competition with itself to better itself. I don’t quite see how velocity does that. I do see how cycle time does that.
Pingback: New PM Articles for the Week of September 2 – 8 | The Practicing IT Project Manager
Interesting points. How would you suggest getting the team involved in visualizing the cycle time? I wouldn’t want it to feel like this is somehow a measure of their success but rather getting them involved in identifying potential or present gaps and then coming up with experiments to address these gaps.
Nic, I’m with you re wanting to make sure the thinks in terms of gaps, not that they aren’t successful. Here are several circumstances where you might suggest measuring cycle time:
If you serve the team and you see delays, you might say, “Hey, do you know about this tool called a value stream map? I think I see delays in the team. I’d like to map/us to map the value stream for a few features/next two weeks and see what we learn.
Every time I’ve been successful with the value stream map, I’ve stressed that it’s a learning tool, not an evaluation tool.
One of my clients says that he asks each of his teams to measure their cycle time. They often have delays because of cross-team dependencies. (See Product Roles, Part 5: Component Teams to Create Slices.) He needs the data to work to create cross-functional teams and make smaller stories across the organization. He’s been at this for several months. The first month, his colleagues didn’t believe the data. Now, his colleagues believe the data and the managers are finally collaborating.
Thanks, Johanna!
You’re welcome, Nic!
Hi Johanna,
We are working solely with measuring velocity and it works pretty (even perfectly) well, which makes this article very intriguing. We are a very small team and although people did come and go at some point, we do have calculated a “per person” point average, which allows as to really take that into account …
That said, we do have that phenomenon that for a story there are waiting times (requested reviews etc). They are though compensated by already starting another story …
Even though I don’t see at this point a reason to change (for us), I’m curious though “how” you measure the waiting time?! I mean, through what tool?
Thanks again for the article
Cheers
Hi Toni, I measure waiting time in as easy a way as possible: If I use cards, I mark the start and end times of work time, often on the back of the card. I mark the start of the wait time and the end of the wait time.
If you use a tool for your cards, most tools have a way to track when the work gets into which column and when it leaves that column.
You said that people start another story when waiting for review, right? That’s a form of multitasking. I recommend against that, and that people work in pairs to not have to wait for review. I have a ton of content about that. Maybe see my flow efficiency series, or the pairing, swarming, and mobbing post.
If what you do works now, you might not want to change it. But, I worry about measuring anything per person when it takes a team to succeed.
Thanks, glad you liked this post.
Pingback: El Cycle Time y otras maneras ver la eficiencia del proceso Ágil - Javier Garzas
Pingback: Are You Too Busy to Continue Learning? | Create An Adaptable Life
Pingback: Measure Cycle Time, Not Velocity – trulySCRUMptious
Pingback: Why Minimize Management Decision Time - Business Agility Conference Global
Pingback: How Early Can You Notice That First Change? | Create An Adaptable Life
What you are describing increase the load on the members of the team. They need to do their job as well as keep track of yet another thing (when did they start working on something, stopped, etc). It increase the cognitive load. People will probably not truly do it, or it will be a gross estimation based on what they remember. It will give a precision of about 2 hours at best.
Using your tool built in time tracking is not gonna be accurate either, because people will probably not rush to the board in order to move the card. Such metrics do not represent the real world, they are not accurate and are dangerous. If the members of the team work as a team, they will send a message to the person directly telling him/her that they have finished their task and the work is ready for the next step. Your metric will show a completely different story than the reality.
If you want to know were there are issues in the team workflow, do a retro, ask the team what can be the cause of not finishing all the PBI in the sprint, or what can we change in order to deliver more. The team will be full of insight. If there is a waiting time problem, the team will talk about it and won’t need all of the time tracking in order to identify “wait time”. People are not robot.
Time tracking is just another form of micro management in my opinion. It does not support the person in a way that just focus on letting her do her job unbothered.
As an example, here is how we solved a few problem in our team last year (the team was created last year).
We saw during the sprint reviews that our PBI were being done in more than a sprints.
The team agreed during the srpint retro that we have an issue at the review step. PBI are being moved to the column but nobody are reviewing. We tried different thing such as planning 2 meetings each weeks in order to present the work to review and assigning it to someone. It more or less worked. We kept having problem with this system, we identified that it is because people are not communicating enough. When the author of the work finished fixing the issues, he did not notify the author, due to timidity or else. The simple fix was to agree that it’s ok to notify by message that the everything has been fixed. Eventually we replaced the meeting by just sending to the group channel the link to the working requiring a review. We no longer have delays there.
Tracking time would have provided no more information, but would have bothered the team member with yet another thing to think about.
On another matter. Having multiple person on the same PBI does not mean that you can skip the review! The point of the review is to benefit from the point of view of a person who was not involved in the work. Otherwise, the person ‘revewing’ have the same tunnel vision than the other one who worked on the PBI. If the bigger item takes time to review, a barrier we identified during one of our retro was that it have a greater entry barrier (who knew!). A fix is to get the reviewer and the author on the same room. The author introduce the subject to the reviewer enough for him to be able to go read the spec and read the code himself.
JS, I see your point about cognitive load. However, how long does it take to either note on a card or in a tool when you took a particular item and when you finished it? Remember, this is not traditional time card tracking. This tracks the item as the item flows through the team. If you prefer, don’t track the time anyone requires to finish “their” part of the work. Instead, track the wait time between people working on the item.
I do use retros to see where we have problems. And that’s where I see we don’t have sufficiently detailed data to be able to make decisions. Clearly, you have a different experience than I do.
Thanks for describing how your team works. You use resource efficiency in your team. If you can make that work, terrific. However, I guess I was not clear enough for you in my description of how a team works together in flow efficiency. When I talk about pairing, I literally mean two people working together on one item, taking turns at the keyboard. In my experience (I have paired since 1982), when two people co-create, they do review as they proceed. Mobbing works the same way. Swarming does require people to decide when to review a different person’s work.
Cycle time is not about tracking the time of a person. Cycle time tracks the team’s work time and wait time for one item. I’m not sure how to be more clear.
If you don’t want to track cycle time, don’t. However, I recommend you not use velocity. Instead, count the average number of stories you do in a time period. Since you use terms such as PBI, I assume you’re using Scrum. Count the number of stories you do in a two-week period. If you are able to maintain an even cadence of the number of stories, terrific. However, that cadence won’t tell you if you have wait states.
Since you talk about sending messages and emails, I guarantee that your team has wait states. Those wait states mean that people multitask while they wait for the next item. If you don’t want to address those wait states, don’t use cycle time. However, my experience is that the wait times overwhelm the work times.
A recent client measured their cycle time. They were able to finish roughly two items a week. Each item only required about 6 hours of work time. Each item had more than 24 hours of wait time. That’s a ratio of 1 hour of work time to 4 hours of wait time. They used that cycle time measure to understand their wait states. (Not a person’s state. The team’s wait states.) They waited for everything: for the PO to explain the story better because they had less-than-effective planning meetings; for design review; for code review; for someone to review the problems the testers discovered; for someone to review the fixes the developers created. The team worked in resource efficiency, not in flow efficiency. All those wait states added up. Yes, they worked in mini-waterfalls. However, many teams do that. You can still work in a mini-waterfall if your team uses flow efficiency.
I thank you for reading and for commenting.
Hi, I am sorry for the delay.
Since we are writing big post, I will quote some part of your post and answer directly below it in order to be clearer if it is ok for you. You can do the same if you find this useful.
=> “JS, I see your point about cognitive load. However, how long does it take to either note on a card or in a tool when you took a particular item and when you finished it? Remember, this is not traditional time card tracking. This tracks the item as the item flows through the team. If you prefer, don’t track the time anyone requires to finish “their” part of the work. Instead, track the wait time between people working on the item.”
The point is not about how much time it takes to note when you started and finished working on a particular item, it is that you need to remember doing it. The team already have a lot to think about, I would rather have them think about the architecture or remember that they identified a problem in the architecture and write it down.
Furthermore, if you want to know the waiting time, you have to track the time anyone requires to finish “their” part of the work. Or I am missing something ?
=> “I do use retros to see where we have problems. And that’s where I see we don’t have sufficiently detailed data to be able to make decisions. Clearly, you have a different experience than I do.”
I fully agree that sometimes you need more data. That is why I view time tracking more as a tool than a systematic thing to do. One would decide to use this tool following a retro where the team think the data is missing and could provide more insight.
=> “I recommend you not use velocity. Instead, count the average number of stories you do in a time period.”
It works only if all your items require the same amount of work. Otherwise from one period to another, you are comparing apples and oranges.
For instance, let’s take a situation where during the first period, you finished 5 items which required a work of 2, and in the following period you finished 2 items which required a work of 5.
Counting average finished items would indicate that the team did a bad performance where they actually performed normally.
=> “A recent client measured their cycle time. They were able to finish roughly two items a week. Each item only required about 6 hours of work time. Each item had more than 24 hours of wait time. That’s a ratio of 1 hour of work time to 4 hours of wait time. They used that cycle time measure to understand their wait states. (Not a person’s state. The team’s wait states.) They waited for everything: for the PO to explain the story better because they had less-than-effective planning meetings; for design review; for code review; for someone to review the problems the testers discovered; for someone to review the fixes the developers created. The team worked in resource efficiency, not in flow efficiency. All those wait states added up. Yes, they worked in mini-waterfalls. However, many teams do that. You can still work in a mini-waterfall if your team uses flow efficiency.”
This is not a resource efficient team, this is a badly organized team.
If you are doing scrum, after the sprint planning, there shouldn’t be question regarding what is supposed to be done, or it should be an exception. If the team uses another framework, well I am sure the framework planned this. If not, maybe the fix is to change framework.
Design review delay is solvable pretty easily. Design review is top priority. If someone finished it’s work, the other one drop what he is doing and start the review right now.
Again, problem discovered while testing are a priority over the new item the current work in progress item. If an issue is found during testing, the responsible developer drop what he is doing on it’s new item and fix the bug right now.
Of course, I don’t know the full story regarding the team you worked with, this is all based on what info you provided me, but only you know the full story.
Would you have data available for review over more than 10 sprints before and after change ? What was the team producing each sprint (both items counting and velocity, in order to compare the information they provide), what was done differently, what was the result ? (Data replicated on multiple team would be a must, but I know it is unlikely since it takes a lot of time. I am asking because you seem to be applying this method to multiple team)
I think the problem I have mostly with your proposition is that it is like going from one extreme (using velocity) to another one (counting finished items).
If the problem you have with velocity is that it vary too much depending on who take vacation and who does not, you can compute a better estimate by factoring the number of day people are working during the sprint. I found this to work pretty well for our team. This way you have an indicator closer to reality.
Jeremy, I have not been able to explain my thinking sufficiently well to you. Let me try again. The time tracking is against the item, not the people. Let’s use the example of a relay team. Each runner needs to run her best race. In addition, the team needs to reduce the handoff time in the race. While we want to encourage people to run their best personal race, cycle time is that overall time plus the handoff time. Many relay runners train the handoffs, not just the run time. If the runners only tracked their time, that would leave them open to bobbling the handoff in the race itself.
In a relay race, it doesn’t just matter how fast each person goes. It totally matters how the team works together. That’s cycle time.
I’m not sure how else to explain the idea of cycle time, especially if you read the flow efficiency series. If you have not read that series, please do. Thanks.
I’m glad velocity has worked for your team. I suspect you don’t have too many experts in your team—that each team member is able to flex to do more work.
However, my experience is that velocity does depend on items being roughly the same size. Cycle time does not require that.
I don’t know how far in the future you need to forecast dates. With any luck, not too far. However, I found that cycle time allows me to forecast with a reasonable plus/minus percentage. Please see Low Tech Way to Visualize Your Percentile Confidence for Forecasts.
If your team(s) always meet their estimates, keep using velocity. However, if your team depends on other teams, or other people, and cannot meet its velocity commitments, you might have the problem I described here: Unearthing Your Project’s Delays. You can just read the part about the UI experts.
I’m not trying to change your mind. However, I do want to make sure you understand me. Given your comment, I don’t think I explained cycle time well enough the first time.
Hi,
“Jeremy, I have not been able to explain my thinking sufficiently well to you. Let me try again. The time tracking is against the item, not the people. Let’s use the example of a relay team. Each runner needs to run her best race. In addition, the team needs to reduce the handoff time in the race. While we want to encourage people to run their best personal race, cycle time is that overall time plus the handoff time. Many relay runners train the handoffs, not just the run time. If the runners only tracked their time, that would leave them open to bobbling the handoff in the race itself.”
From the article: “Note every time the work changes state: is it a work time (above the line) or a wait time (below the line)”
A work changes, as I understand it is the moment when somebody started or finished working on something. The developer start working on the item, he notes the date, then when he is done, he write down the date. The tester start working on the item, he/she notes the date, etc…
It means wait time = Next person start date – previous person end date. Or I am not understanding correctly ?
If I don’t get it correctly, can you give me an example of how it is being done concretely please ? How do you compute the waiting time without tracking the time at which each person started and finished working on an item ?
=> “I’m not sure how else to explain the idea of cycle time, especially if you read the flow efficiency series. If you have not read that series, please do. Thanks.”
I read it already after your first answer since it appeared that I was missing something. I find it too abstract and lacking in concrete example. How were working the teams before, what change gave what result.
=> “However, my experience is that velocity does depend on items being roughly the same size. Cycle time does not require that.”
Velocity literally does the opposite. To each items is given a complexity (story point). It means that you can have items of varying size. In the end, the velocity is the addition of the complexity of all the cards that were finished. If you have a good scale, then you should be able to finish more or less the same quantity of complexity each period/sprint. The goal being to stabilize the variance between each periods in order to be able to predict when what will be finished after multiple periods.
For instance, in our team, we have a complexity scale following Fibonacci from 1 to 13. Items with 13 require 3 weeks to be done with multiple developers working on it before being able to move to the test phase. We cannot break the item which have a complexity of 13 more, otherwise it would literally be worth nothing and only add management overhead.
From your article: “I also recommend you count stories. It doesn’t matter what the points are. If your team always finishes two stories in an iteration, you have a cycle time of 5 days.”
This is basically the formula to compute the velocity when every item have the same complexity. You just set the complexity to 1. It makes sense only if all your stories require the same amount of work, or that you take always 2 items with the same cumulated complexity (1 items which require 4 days and one which require 1 day to complete, then 1 items which require 3 days and one which require 2 day to complete). Otherwise this is not possible.
It is not because you don’t evaluate the complexity of each items that there is not a difference of complexity between each items.
In “Low Tech Way to Visualize Your Percentile Confidence for Forecasts”, you talk about having multiple item being worked on simultaneously. It means that you are not in one item swarming as I came to understand it based on your precedent answers.
Ok, I think I am starting to understand the situations in which were the teams where you applied this system, and therefore to what team what you are describing is applicable.
Your teams are not using SCRUM, so they have no notions of engagement. It means that they do not aim at finishing the items they agreed they can do at the start of the sprint/period. It means that you are left with only a velocity. You can therefore end up in the situation where you have a high velocity but items are being worked on during multiple periods for no reason but that people are not planning on maximizing the number of item done at the end of the period. So, since there are no engagement, the team do not have conscience that there is a cost of delay problem due to the time it requires to finish each items.
In order to compensate the lack of visibility for the delay problem, you started tracking the wait time of each items. Did I understand it right ?
Can you describe how the team where you applied your system were working ? What was their habit ? What methodology did they use ? It would be helpful in order to know in which situation your system has been tested and could be use.
PS: I am not saying that SCRUM is the answer, just doing a parallel with what I know and practice.
Jeremy, I don’t know how to make my writing any more concrete. Yes, all these teams used Scrum as their agile approach. I hope your velocity continues to work.
Pingback: Where Can You Create Reinforcing (Virtuous) Feedback Loops? - Create An Adaptable Life
I’m sorta new to the study of cycle time. I discovered this article because, after having worked with story points and velocity for awhile now, I see their limitations and I’m looking for something better.
But I am confused by a few things and suspect it means I don’t really understand.
Like some other commenters, I am having a hard time reconciling this…
“If your team always finishes two stories in an [10 day] iteration, you have a cycle time of 5 days”
with this…
“Cycle time is the entire time it takes a team to finish something on their board.”
Because, assuming you’re talking about a 2-week (10 day) iteration…
If each item takes all 10 days, for example, then why, according to your definition, isn’t cycle time 10? After all, it takes the team 10 days to “finish something on their board”.
I feel like, at this point, after having read several articles from different authors, the industry is not doing a good job of defining terms or making things clear; and it’s leading to confusion. That led me to this: https://itsadeliverything.com/lead-time-versus-cycle-time-untangling-the-confusion. It confirmed that I’m not the only one.
Regardless, there are things that just make common sense: Collaborate, limit context switching, maximize team flow, make your stories small. Everybody seems to acknowledge these things, but they still apply them in their resource efficiency mindset. “Yes, let’s do these things; but only to the extent that we maintain resource efficiency.”
Also, based on my understanding of the definition of cycle time, it seems to me there is a point of diminishing returns. I’m definitely not a “resource efficiency” guy. I appreciate the idea of “flow efficiency”. But, given a team that is doing a good job at limiting WIP, then in order to reduce cycle time, it seems one strategy is to continue to reduce story size; and there’s a point at which that is counter-productive, isn’t there?
For example, if you can get 1 story done in 2 days, yielding a cycle time of 2, why is it better to split that in half if it results in it taking 3 days? You’ve cut your cycle time down to 1.5 days after all; but you’ve reduce your throughput. Right?
Thanks for helping to educate folks on this topic.
PD, thanks for your comment and for the link. Let me try to unpack some of this.
Definition: Cycle time is the entire time a team requires to start and complete a unit of work. We call this work stories.
Let’s start with the first two examples, where we measure the cycle time, the actual work and wait time for the collaborative team and the team that works mostly as individuals. Did those two value streams make sense to you? If so, that’s the “real” way to measure cycle time.
My assumptions: the team can finish the work. I hope to deployment, but the team no longer has any other touching to do on that work.
Did that make sense?
If so, measure the cycle time for several features. At some point, you can build a time series chart as in the Low Tech Way to Visualize Your Percentile Confidence for Forecasts. You might need data from the past six-eight weeks to get useful cycle time measures.
That’s the measure-your-way to cycle time.
You can also count your way to a rough approximation of cycle time. That’s the example of you normally finish two stories per iteration, five days per story. This works if you don’t have the detailed measurements of the last few weeks of data, but you’d like to start thinking about cycle time.
You can visualize this with an iteration contents chart. (I have more discussions of this chart both in Manage It! and Create Your Successful Agile Project.) Online, see What’s an Agile PM to Do? and Iteration Contents Show What the Team Completed.
Now, based on that iteration contents chart, you can count what the team typically delivers in an iteration.
This post has two options for cycle time:
1. Measure the real cycle time with delays by creating value stream maps.
2. Count what you deliver in time units of weeks, and see what that gets you.
The measurement is accurate. The count is an approximation.
I’ll start a new comment for splitting stories because this is long enough.
So if cycle time is the time it takes a team to deliver a unit of work, does it make sense to split stories?
Yes, and only if there is value in the split.
Let me wax a little more loquacious:
Here’s what we know about large work:
So, in general, we want to keep our WIP (Work in Progress) low and our throughput high.
If your team is already right-sizing stories to keep your WIP low, and collaborating as in flow efficiency, maybe you’ve made your stories as small as they can be. That’s where I would measure cycle time to make sure we don’t have a lot of wait time. My clients often have a lot of wait time, so when they see their wait states, they don’t have to make the stories smaller. They reduce the wait times in the system and they get a lot more throughput.
Did that make sense?
(I guess I need to write a Little’s Law post for teams and managers. Thanks for that idea.)
Yes, it makes sense. Thanks.
In the environment I am in, where we have 2-week sprints with teams of 6-9 devs and testers across the entire application (yes, it’s large: 150+ teams), that there is a drive to make stories small, but it’s not “Is this story the minimum required for this user to get sufficient value”, because that would result in stories that are too big and cannot be completed in a single 2-week sprint. Not with a resource efficiency mindset, anyway.
So what happens is that stories get broken down into “What’s a small atomic piece of functionality that can be tested through either the UI or the service API?” So, for example, we might implement a happy path first in one story, and then put edge cases and error cases in other stories. That’s a very common pattern for us. I’m very familiar with vertical slicing, but my experience (so far) is that that is hard to do. Again, perhaps a consequence of the organization trying to be resource efficient and the fact that it’s led to what I think is significant over-specialization.
I hear people talk about creating 2-day stories in a flow-based approach. I cannot imagine how to do this with a new feature and meet “Is this story the minimum required for this user to get sufficient value”. I feel the opposite — that stories would need to get larger.
PD, I would call your environment a “program,” where teams might have their own goals/deliverables, but all those deliverables contribute to an overall business deliverable, the product.
If you want resource efficiency, you can’t effectively use any agile approach. Sure, you can do something that’s probably better than it was before. But I am sure I would not recognize that as an agile approach. I realize this is primarily a management problem.
Re 1- or 2-day stories, see Consider Product Options with Minimum Outcomes. A valuable result does not have to be for the end user. A valuable outcome might be to show the result of an experiment.
Yes, vertical slicing is hard to do. It’s even more difficult if you don’t have a cross-functional team, or if everyone works on their own story.
The Prags posted an excerpt from Create Your Successful Agile Project here: Agile Is a Cultural Change. You might also like Agile Approaches Require Management Cultural Change.
Agile approaches are not a different lifecycle. They require a different culture and reward system, all based on collaboration and flow efficiency. (The Modern Management Made Easy books discuss the necessary change in management behaviors.
Let me pop back up the stack a bit.
And the more your managers think in and reward heroes and individuals, the less likely you can do any of this.
Which brings us back to why I recommend you measure cycle time. As far as I can tell, every single manager wants to know when “it” will be done. Cycle time can tell you. Velocity cannot.
I am not saying that you and you alone should stand up to management and try to change anything. That’s too exhausting. However, you might start with your team and explain the various problems. If you measure your team’s cycle time, could you change anything just within your team? That might help all of you.