Storypoints with an ever-changing team

It's the work on the backlog that should change, not team membership. You need a stable team in order to inspect and adapt, and for meaningful metrics to be elicited and compared Sprint by Sprint. What you have described - rigid requirements and an unstable team - is an inversion of this way of working.

BTW I would observe that requirements are *not* in fact rigidly defined in your organization. The evidence is the fluctuation in team membership. The implication is that team composition is being interfered with in order to support variable work elsewhere.

I'd suggest that this work be put on the team backlog in the first instance, then the team can self-organize themselves in order to handle it. I'd expect this to expose weaknesses in Product Ownership...it usually does.

Ian,

Good points, as always. Reasons for the fluctuation in team membership vary. Some team members are assigned to two projects 50-50%, except on the weeks they are on-duty (one week at the time), in which case their capacity might vary between 0 and 50% depending on the number of cases they get from production. Other members might be suddenly asked to do some urgent investigation. Again, given the environment we work in, I'm wondering if using storypoints not only doesn't give us any benefit but actually hampers our ability to estimate and follow progress.

> given the environment we work in, I'm wondering if using
> storypoints not only doesn't give us any benefit but actually
> hampers our ability to estimate and follow progress.

It's not that story points impede your ability to estimate, but rather that any estimates would be of limited value due to inconsistencies in team membership. Estimates are made, after all, by a team for themselves. Change the team and what use are their estimates now? Who are they for?

In this situation - and assuming I had absolutely no control over team stability - I'd consider writing very small backlog items to improve liquidity, and just count stories done. Time onto backlog, time actioned, and time completed are recorded for each story. This way estimates are taken out of the equation...it is the actuals that are being tracked. In effect each backlog item is tentatively sized as 1. This also reduces the chances of impediment as I said earlier, and usually improves analysis. The metrics would show the impact of unstable membership on throughput and cycle times. Martin Fowler has written about the story counting approach: http://martinfowler.com/bliki/StoryCounting.html

Currently the process something like this. The dev team is asked for time-based estimate for a feature. (The way the feature is defined is usually somewhat lacking for reasonable estimation, but that's another story.) We, the senior devs and architects, break the feature down to subfeatures (usually something like DB changes, BL changes, service changes, UI changes), and give those an estimate and the total tells us how long it will take to finish the feature. The management then (I suppose) adds buffers for management etc. and markup. This will be the fixed-price bid. Now, when we start to work on the feature, we create Product Backlog Items for each subfeature that we had on the initial estimation (we use TFS). We then break the PBI's down to tasks and add an original estimate of how long it will take to finish that particular task. The sum of all tasks under one PBI ought to be the same as that of the original subfeature. This isn't always true since we have now broken the problem down further and have a better understanding of the work to be done. If this happens, we notify the management. At the end of each day we update the remaining and finished hours on each task. (We don't touch the original estimate.) Management can generate a real-time reports on our progress. They use this to track progress, how well we are keeping to the original estimates, and also resourcing.

What some devs in our teams want is to use storypoints instead of man-days in the original estimation (of sufeatures). The tasks would still be tracked based on hours. I don't quite see how that would improve the accuracy of our estimation.

Hi Rubio,

Allow me to share some of my thoughts....

I don't think using Story points will get you better estimates based on your current setup. Playing Devil's Advocate, consider this question --
Assuming you'll always have the same people, Sprint after Sprint, will your estimations be 100% accurate and satisfy management....?
(I do think story points will help in other areas, though. Won't address just yet.)
.
.
.
Remember -- its an estimate only, and one is making a forecast during Spring Planning.

Velocity tends to be a misused and misunderstood concept. This term was actually removed from the Scrum Guide a few editions ago.
(This doesn't mean you should take this away, or there isn't a benefit to this.)

Here's what I would consider --
A) At the Sprint Planning, figure out who's available, and for what duration?
-- This could be vacation, company holidays, moving to another project, etc.
B) Allow the Dev Team to pull in items after this discussion
C) Ensure the PO is aware of this and adjust any forecasts or communicate with the Management
-- The SM could raise the moving of people about as a loss of productivity, etc. to the Management, if it is so.]
-- There's already been plenty of discussion on moving people about and I would agree -- try to get a stable team, otherwise every Sprint change, one can even debate that's its no longer the same team and historical data may not have the same value.
C) At the Retrospective, discuss how they did

Some key items --
1) Ensure people aren't moving mid-Sprint, UNLESS it was agreed upon during Sprint Planning.
D) Consider reducing the Sprint length!
E.g. What would be the impact of having a 2-week dev cycle where a developer is there only 1 week, as compared to a 1-week dev cycle, where we know a developer isn't going to be there in its entirety?
.
.
.
Lastly -- try to think of it this way --
Velocity is the outcome of something; It isn't "calculated."
Tomorrow's weather is just a forecast. However, tomorrow or day after, we will have known the outcome of the skies, etc. We may have tools to measure, but its only there to measure an outcome.

I think in the earlier post, you considered not capturing velocity. This is also worth considering. I would have the SM how this is beneficial to the Scrum Team, and those outside.
(Perhaps capture, but decide who it is shared with, etc. can also be a consideration.)

Hope some of this helps.

Thanks Nitin,

First of all, we're not looking for 100% accuracy. If we did, we'd call them facts. Estimates always have a degree of uncertainty, hence the name. What we are looking for is to minimize the uncertainty.

As for the points you are making, point A we do already. Not sure what you mean in point B. PO and SMs decide what to put in the sprint backlog after discussing priority and focus with PMs. This is how I think it should be. Point C is also obvious. Point D, sprint length we haven't discussed. It might have a positive effect on the changing capacity issue. However, I already think the Scrum rituals take way too much time compared to the benefit they give.

The motivation to use storypoints for estimation, as opposed to hours or days, is to improve estimation accuracy. For the planning and monitoring done by the management we have to produce time-based reports, how much time we have used (evidence so far), and how long it will take to finish (estimate). So we _have_ to convert storypoints into units of time. Period, no discussion. Even if using storypoints would increase the accuracy of our estimates, given these constraints I don't see how it would be possible, or worth the effort.

> We, the senior devs and architects, break the feature down to
> subfeatures (usually something like DB changes, BL changes, service
> changes, UI changes), and give those an estimate and the total tells
> us how long it will take to finish the feature. The management then
> (I suppose) adds buffers for management etc. and markup. This will
> be the fixed-price bid.

That isn't Scrum, because (as Ken schwaber has put it) the only purpose of a team's estimates is so they can get their arms around how much they reckon they can do.

What you have described is, however, pretty much in line with what happens in the Scaled Agile Framework (SAFe). In that approach it is considered quite reasonable for a team's estimates to be used in a predictive manner, even to the point of being able to bid for work as you describe. This is, to say the least, a highly controversial matter.

> For the planning and monitoring done by the management we have to
> produce time-based reports, how much time we have used (evidence so
> far), and how long it will take to finish (estimate). So we _have_
> to convert storypoints into units of time. Period, no discussion.
> Even if using storypoints would increase the accuracy of our
> estimates, given these constraints I don't see how it would be
> possible, or worth the effort.

Darned right, and it wouldn't be worth the effort...at least not from the team's point of view. The problem is that the team has lost ownership of its estimates. It is now management who are driving the estimation exercise with a view to measuring and monitoring teams. Frankly that is not what estimates are for in an agile way of working.

Hi @Rubio.

I apologize for the late response. Also, some of the writings may be obvious, but I tend to write more broadly at times since there are a lot people reading, which may benefit.

Allow me to elaborate on a few points --
B) The Dev Team should be "pulling" rather than having the work "pushed" out to them. This is subtle, but quite powerful at the same time. The Scrum Master can facilitate as needed.

D) Things typically get adjusted with the Sprint events. i.e.
Sprint Planning - 8 hours for a month long Sprint, and depending on the cycle.
Daily Scrum -- Same time, same place, 15min timebox.
Sprint Review -- 4 Hours for a month long Sprint, and shorter for a smaller dev cycle
Sprint Retrospective -- 3 Hours for a month long Sprint and shorter for a smaller dev cycle

Shortening the Sprint length is just an idea. I would check with the team what makes sense. If its not best for all, you can ignore it.

For your last point, I echo Ian's sentiments. What I have seen with some teams (middle ground) is that having a range of hours, mapped to Story points seemed to have satisfied some people. E.g. 1 point is about 5 hours or less, 5 points is 25 -- 30 hours, etc. This still isn't what you may be looking for, but may be a little closer.

We are better at comparisons, rather than estimates, so I would continue to see what works as a relative measure. This continues to be a challenge for a lot of organizations, including some teams I am working with.

That isn't Scrum, because (as Ken schwaber has put it) the only purpose of a team's estimates is so they can get their arms around how much they reckon they can do.

My point exactly.

What you have described is, however, pretty much in line with what happens in the Scaled Agile Framework (SAFe). In that approach it is considered quite reasonable for a team's estimates to be used in a predictive manner, even to the point of being able to bid for work as you describe. This is, to say the least, a highly controversial matter.

I'll take a closer look at SAFe. Thanks.

We are better at comparisons, rather than estimates.

Excellent point. Thanks.

PS. I'm starting to like this forum. People are knowledgeable and civil, unlike some other forums.

PS. I'm starting to like this forum. People are knowledgeable and civil, unlike some other forums.

Yes! My thoughts exactly.