Can Story Points be used in a Kanban for forecasting and predictability?

What sort of delivery would then be forecast? What would become predictable?

@Ian Mitchell, how much work can be completed would become predictable essentially the of throughput would be expressed in points per week instead of items per week

Would throughput expressed in points be in line with the purpose and philosophy of Kanban?

@Ian Mitchell, with the approach I am discussing, we’re not changing the purpose of the Kanban approach, atleast that’s what I believe (unless someone explains why)

I’m just saying that, if we proceed the traditional way, then the work represented by each card needs to be uniformly sized or should be of similar size. If this is not possible, then we may have a skewed throughput if we use items/week.

if we use points, we’re only expressing the throughput in a different way. Therefore the only modification would be in the way WIP is expressed and throughput as points/week instead of items/week. This change should be made transparent to everyone reading from this board too.

based on the above, I believe the purpose and philosophy of kanban isn’t being violated, but please advise where you think my understanding could be wrong. Thanks.

work represented by each card needs to be uniformly sized or should be of similar size. If this is not possible, then we may have a skewed throughput if we use items/week.

Some thoughts:

• Do you think there may be variation week to week regardless of whether item count or points are used?

• Do you believe that the overhead involved with estimating items provides you with increased visibility and accuracy into what can be achieved week to week?

• Would you require revisiting an estimate before the item is pulled into progress, to take advantage of any new information or learning gained since the original estimate?

My personal preference when working in Kanban is to rely on a throughput count instead of relative estimation in story points.   Any variability in item size will be absorbed over time to provide a reliable metric around the # of items that can be completed each week.

Do you think there may be variation week to week regardless of whether item count or points are used?

@Timothy Baffa, I know there will be extreme variation because for the kind of work the team I am working with is doing, their metrics like Cycle Time and Throughput will be skewed because of some pieces of work that are outliers.

my understanding in using Kanban metrics is that the items would be similar in nature and hence its size also would be similar.

In fact, there is no overhead in what I was suggesting. Instead of calculating throughput as items per week, can't we consider story points per week?

If you're using Little's Law then it's important to remember that it's a Law of Averages. The assumptions within the law do not dictate that items need to be similar in size (although I agree that right sizing is beneficial where possible). 

One of the assumptions is that Cycle Time, WIP, and Throughput must all be calculated using consistent metrics. Whether you use PBI's complete or story points complete you should be consistent and know that if you're using the Cycle Time = WIP / Throughput calculation it is best used as an average. 

You can find clever ways to call out these outliers if you put them on a scatterplot. For instance you could end up that 85% of the time the team will complete at least 20 story points per Sprint knowing that 15% of the time you will have Sprints with outliers where less is completed. 

In fact, there is no overhead in what I was suggesting. Instead of calculating throughput as items per week, can't we consider story points per week?

Steve, there is indeed overhead with identifying a story point value where none currently exists, and maintaining that story point value up until the point the item is moved from "To Do" to "In Progress".

Do you believe that the time and effort spent assigning and maintaining story point values is offset by increased accuracy into the amount of "work" the team can complete each week?   

To take this discussion one step further, do you have any evidence that a story point approach provides better planning data than a straightforward, lightweight, item count approach?

Predictable flow relies on a steady arrival and departure rate to the flow.

Regarding sizing of items, a policy to enable right-sizing is usually sufficient. Right-sizing does not have to be same-sizing.

Perhaps we have the following columns: To do, Writing, Ready to Review, Reviewing, Ready to publish, Publishing, Done.

For simplicity, let's also say each column has a WIP limit of 1, and let's also assume that a right-sized item typically takes 1-3 days to write, 1-3 days to review, and another 1-3 days to publish.

Now imagine we introduce an item that is 10 times our right-size.

It's going to spend 10-30 days to complete each stage. Within 2 to 6 days, there will be nothing to review. Within 4 to 12 days, there will be nothing to publish either.

The only good news is that once this large item is written, it won't need to wait to be reviewed, because the reviewer is not busy.

But then we see the real fun start.

Within 1-3 days, something else is in Ready for review (and it's going to be stuck there for a while).

Within 2-6 days, the team have a dilemma, as both the Writing and Ready for review columns will reach their WIP limits of 1. The team are then faced with the challenge of temporarily adapting their processes, or accepting that writing stops. Both obviously have consequences.

Meanwhile let's not forget that someone is paying a publisher who isn't needed right now.

Not only is our large item slow to make it through the workflow, but think about the right-sized items that are picked up directly afterwards, and spend far longer than normal in a queue, waiting to be reviewed, then published.

My point is that the estimated size of an item doesn't necessarily map proportionally to the cycle time or throughput, because wrong-sized items introduce different bottlenecks and cause or eliminate queues in a way that the system might not be designed to cope with.

If you are using Kanban within Sprint boundaries (i.e. Scrum with Kanban) then I see benefit in pointing the stories in order to forecast the Sprint Backlog.  But if you are doing just Kanban, I don't see much benefit to pointing stories.  In my experience with Kanban, the focus has always been on moving the top story on the board from Idea to Money in the shortest amount of time possible without sacrificing quality.  If the top story is 3 times larger than the next story I wouldn't expect the team to break that story into thirds. I would just expect them to move that story across the board. 

I am on the "right sized" vs "small sized" bandwagon. It does help teams perceptions of success if stories are similarly sized so that movement is seen on the board but I don't see it as a necessity. Measure throughput and as with any metric the data points will normalize over time. 

As a suggestion, instead of doing Story Points it might help the team to use t-shirt sizing instead.  Points often lead to obsessive behavior over the points and time to done as we have seen in MANY posts in this forum.  However, t-shirt sizing can help a team in comparative sizing without the need to count. Human nature is to do math when numbers are involved, especially with software developers.  

@Daniel Wilhite, @Simon Mayer, @Timothy Baffa

The reason I was talking about using story points was because of a specific situation I've encountered where one team is using Kanban and other teams are using story points. This team chose to follow Scrumban, something which I personally don't recommend.

Now, I am not saying I am for this approach. It just seemed reasonable to have all of them use story points so that they kinda communicate the same language. Also, I am reducing the scope of the context here. Overall the whole setup is messed up but I am just making things happen as my words to not follow this fell on deaf ears.

So this team is currently maintaining story points as well as counting the number of items to get to the metrics like Cycle Time, Throughput and WIP.

Now, in a Kanban setup normally these values would read something like Cycle Time = x days, Throughput = y cards / week and WIP = z items

the tool that this team is using allows them to use story points, hence I thought by sizing the stories like they used to or are trying to emulate from what is commonly incorrectly taught as part of Scrum they could avoid all this unnecessary confusion and overhead. Atleast to get them started to begin with.

So as @Tony Divel, previously mentioned, if Littles law is based on averages, then why can't I just size these items/stories using story points.

My Kanban metrics would still be following the law of averages and would look something like this

Cycle Time = x days, Throughput = y story points / week, WIP = z story points (i.e. sum of all story points in progress or in the cycle)

I am not saying use both items and story points but instead just use one or the other. In my opinion, if the organization feels comfortable using story points then the above suggestion still works as far as Kanban metrics are concerned.

Steve, a few comments/concerns on your most recent post.

It just seemed reasonable to have all of them use story points so that they kinda communicate the same language. 

This goal may have unintended and confusing consequences.   Under this approach, how can you ensure that management won't seek to normalize SP's across teams?   By imposing story point use, you may be inviting SP comparisons across teams, which may set false expectations and possible "gaming" of story points.   

then why can't I just size these items/stories using story points.

I am assuming that the team (and not you) will be sizing/estimating the items, yes?

Has the team cited poor planning and forecasting as an issue?   If so, what has the team suggested to use or experiment with to help their planning and forecasting?

if the organization feels comfortable using story points

Using story points for what?   Does the organization understand that SP's are for the team's use only, and should never be used in any type of metric?

This goal may have unintended and confusing consequences.   Under this approach, how can you ensure that management won't seek to normalize SP's across teams?   By imposing story point use, you may be inviting SP comparisons across teams, which may set false expectations and possible "gaming" of story points. 

@Timothy Baffa, I am sorry that some info is getting lost in the process of trying to articulate what I have in my mind and I hope I can explain it further. I am 100% sure that the use of story points won't have the unintended consequences that you highlighted. It has been made very clear that Story Points are not a measure of success of a team or of the collection of teams. Gaming of story points is a risk anywhere it is used and not just in this particular case. We are ensuring that when teams try to gamify we teach them the purpose of why Story points are used in the first place. Yes, it is the team that does the estimates, I just spoke from their perspective.

Using story points for what?   Does the organization understand that SP's are for the team's use only, and should never be used in any type of metric?

Story Points are being used for the same reason it is used in every other organization. Typically, this is represented as Velocity. Now, here's the thing, If my team's velocity is 40 Story Points for a 2 week Sprint, then if I have a Backlog of 450 Story Points, then what is the forecast of how many Sprints it may take to finish the work? I hope we are in agreement that this is where we generally find the use of this practice helpful i.e. for forecasting and planning.

Remember how I said this particular team uses Scrumban?They need to be in a position to forecast what they can complete from the same backlog as other teams. Like I said, if you try to go into depths of this awkward structure, we can keep exchanging a lot of thoughts on the flawed approach.

If Kanban is based on queuing theory and Little's Law, then the metrics are following the law of averages. It doesn't specify the unit of measurement. In general it is items or cards. I am going to assume here that each card/item is not an exact and equal unit but close enough.

Now, going back to the use of story points in for Kanban metrics. Let us assume that I have 3 stories each sized at 1, 3, 5 story points respectively. Therefore the total WIP wiill be 9 Story Points. Assume these stories get completed at different rate, then the average of that time will be our Cycle Time in days or hours etc. Our Throughput will be 3 Story Points per week (assume the per week constraint is applied by the tool we use). 

Now, just like the previous example, knowing that our Throughput is 3 story points per week and our backlog is 450 story points, can't we forecast how many weeks it may take for us to finish?

Now, I am not saying I am for this approach. It just seemed reasonable to have all of them use story points so that they kinda communicate the same language.

OK, I understand you've simplified the context a bit for us, but from what you say, if I was in the development team, I can imagine how I might react.

I'd want to find a system that works for all teams.



If the teams are working from the same backlog (i.e. they're collaborating on the same backlog), I would most likely want to adopt the same estimation process as the other teams. I may make the case not to use points, but I would be prepared to compromise.



If I'm working on a distinct product, and my team has its own Product Backlog, and we're forced to use story points, despite throughput being sufficient for us, I'd probably estimate everything as 1 point.

If as Timothy suspects may happen, there are comparisons about the number of story points, I might start estimating everything at 100 points.

 

@Simon Mayer, you've come very close to what I was trying to explain and as you rightly mentioned it is to find a process that works for all teams so that they estimate in a similar manner.

As I elaborately mentioned above, even though the team structure is ridiculous, gamifaction and comparison of teams based on story points are definitely avoided and I am not concerned about that happening.

Further, the reason this team is choosing this approach is because they want to look like they are doing Scrum but behave like Kanban; meaning they cannot guarantee a "Done" Increment at the end of a two week timebox and they want to keep doing the work until they finish. There is no Sprint Goal etc. This is what they call ScrumBan and it is not Scrum. It just an excuse to masquerade around by saying they are benefitting from both worlds. I've strongly recommeneded Kanban instead and thought that by bringing the metrics in a manner that is similar to the practices of the other Scrum Teams, this Scrumban would stop! :)

Done well and for the right reasons, Scrum and Kanban can be combined to great effect, but adding Kanban to Scrum should not invalidate Scrum.

It just an excuse to masquerade around by saying they are benefitting from both worlds.

Is there a desire from anyone to have transparency over the value delivered?

Is anyone accountable for limiting the risk of investments, that might provide a reason for timeboxing?

Is there a desire from anyone to have transparency over the value delivered?

Is anyone accountable for limiting the risk of investments, that might provide a reason for timeboxing?

I don't think there is any negative intention to limit transparency but the practice is kinda odd in its very existence but unfortunately there are a lot of people in abundance who claim to know and understand agility, scrum etc who end up being in senior positions promoting and supporting such practices.

However, I still wanted to ask the community if using story points instead of item or card count would negate any of the benefits of kanban as such? I don't see anything wrong even after examining this from multiple perspectives. If there is a clear cut reason, please elaborate, i'd like to learn.