What approach of story points suit our team

Question

We are distributed development team in three locations. In each location we have between 2 to 5 developers. We conduct daily standup via Skype. However, we have not been using story points. We just assign tickets most of the time based on each developer opionion of his/her capacity.

The problem is, before I join the team as a scrum master, the team tried to use story points. They ended up (according to the rest of the team), spending more time arguing about one story points than what the entire planning session expected. Therefore, they dropped it. Now I joined the team recently, we had discussion, and we agreed we need to use story points in effort estimation, so that we can have a better picture of our commitment versus accomplishment. In addition it can help us in the future, to draw some useful conclusions.

There is a challenge I can see from now. The developers most of the team are involved in developing their own small projects (microservices), that are most of the time are irrlevent to each other - at least at the early stages. This results in developer x knows nothing about developer y work. As a result, we all discussing story points of certain developer seems to me unfair, impractical.

I am thinking how to approach this situation. If allow each developer to estimate his/her story points freely, we could get for the same task 21 story points from developer x, and 3 from developer y (although both spend the same erffort/time) on that task, but their measurements are different, we do not all agree on a benchmark.

What could be better approach, to use story points in a useful way, but without arguing or dictating to developers the estimates? (I also notice, when developers discuss story points, the seniors tend to have the final say although it is not their task, because they think the task is simple. For junior, there is a lot to learn and the task might take longer. I also want the juniors to have a say for their own tasks)

Answer 1

It sounds like you've got a few layers of challenges. First and foremost, it doesn't sound like you have a team so much as a group of people that have been put together on an org chart. If the different team members can't support each other, then you'll lose most of the benefits of a team and team-based estimation is useless.

If that is the case, then your first priority is to build a team where each member has at least a few people who can support them by assisting and/or taking over work if needed.

Once you have that, Planning Poker is probably the technique I'd point you toward because it'll force conversations in the team. As a good facilitator, you can cut off conversations that aren't adding value (like squabbling over small point differences without actually uncovering anything new about the work). But early on the conversations will be longer because the team hasn't shared enough knowledge or learned how each other works and they have to get through that phase before things can go quickly.

Obviously, there's still a job to be done, but even if you get to estimating a few stories per sprint together as a team that'll start the ball rolling.

Answer 2

It seems to me like you have two issues: lack of knowledge dissemination, and lack of an estimation benchmark.

Knowledge Dissemination

Currently it looks like all of your developers have a bus factor of one. If any of your developers gets hit by a bus (or quits, or gets fired, or goes on a long vacation, etc.), then what happens to his/her project? S/he's the only one who knows anything about that code.

This is a problem above and beyond estimation difficulties (though it feeds into that as well). This is a serious risk in its own right and needs to be mitigated. Off the top of my head, I can think of four possible mitigation strategies: code review, pair programming, having multiple developers work on each project (swarming), and extensive documentation.

Given the nature of your work (many small projects, so swarming might be excessive) and your distributed Team (so pair programming becomes more difficult), I'd suggest code review.

Estimation Benchmark

There are two ways of forming story point benchmarks that I'm aware of: ideal man days and a benchmark story. The problem with ideal man days, however, is that it, like your current approach, does not take into account skill differences between developers. So let's look at the second option.

The idea behind this is you start by taking a 'typical' story (that you have already completed). You say "This story is one story point." Then, when a new story comes along needing to be estimated, you compare it to your benchmark story; if it's about the same amount of effort, 1 point. If about thrice as much effort. 3 points. If about half as much effort, 0.5 points. As more and more stories get estimated, your mental model of the benchmark will evolve ("This story seems to be close to stories 34, 37, and 46, which were all 5-points.")

The advantage here is that there is no actual mapping between story points and time for an individual. A 1-point story could take a senior developer four hours, while it takes a junior developer 2 days. In which case, most 3-point stories would take a senior developer 1.5 days, or a junior 6 days. You're now mapping story points to the amount of relative effort a story requires (which is irrespective of any given developer's skill level) instead of to time (which is not).

The downside is management can no longer get a direct estimate of how much actual time an individual story will take... but they shouldn't even be asking that in a Scrum environment, anyway. They can determine how long an individual iteration can take, given that that is based off of the Team's velocity.

Planning Poker

Finally, as mentioned already by Daniel, make sure you're using Planning Poker. There are various free tools available online to accommodate this for a distributed Team. Make sure different estimates don't devolve into arguments over who is 'right'. Whenever a large discrepancy occurs, the Team needs to ask questions to find out why. If there's a disagreement, then the Team needs to discuss the story in order to turn up new information. If it starts turning into an argument, just take the average between the two and move on. Make sure the senior developers aren't leading, either - everyone needs to have an equal voice.

Answer 3

I concur with some of the other points made, specifically:

1. Not really a team and sounds more like multiple teams of one.
2. Knowledge dissemination is also an issue.
3. No real benchmark for the estimating.

I would add the focus of the question seems to be on finding a tool to overcome...something?? which makes me curious. What interactions are you trying to facilitate? What are the team and the business not getting?

Having said that, I hope you will allow me the following. One of my favorite lines from an Agile Coach I know is: Welcome to Scrum, where the stories are made up and the points don't matter.

It doesn't matter how many points you got done...at least not to an end-user or consumer of the product. One of the drawbacks to story points is that they can quickly turn into a way for the business to measure the team; this rarely ends well for the teams. Just a public service announcement.

Pair programming (or peer review) can help with the first two issues. Planning poker is a decent way to build consensus and discussion.

I might offer something else; so, to the question.

Find a baseline - each Sprint

You could do something like this.

At the beginning of each Sprint, have the team look at the prioritized backlog and pick the smallest thing that's somewhere at the top. Make that your one (1) for the Sprint.

Now, look at the thing at the top of the backlog. How many times more is it than the other? If the team says it's smaller, then you've chosen the incorrect one for the Sprint.

Then the question is, "Do you think you can get it done given all the rest?" If the answer is yes, bring it into the Sprint...then on to the next.

This is per Sprint relative sizing.

(Just in case it's not clear why.) The team is sizing things relative to a baseline selected each Sprint as opposed to comparing themselves or other things in the backlog to past information.

I appreciate this approach because it doesn't tie a point to a unit of time, which tends to happen when things like velocity and number of points completed are monitored. It can also stop the business from trying to project into the future of when something will be "done", which is its own blessing and curse.

But, the fact remains, the points don't ultimately matter...unless there's a clear, distinct, and embodied why; without it, it's a mechanical device the team (yourself included) thinks will help with...something??

Why?

What is the benefit to the universe that the team hopes using points will accomplish? When they commit to a Sprint, do they get the work done? If so, what does an estimate do (they accomplish their mission)? If not, how will an estimate help overcome overcommitting (the problem of not estimating well still exists)?

If the individuals aren't dependent on each other, for the most part, what does it matter if Sally estimates something as 50 points and Saim says its 10? Who's actually getting the work assigned to them? Is Saim dependent on Sally to get it done? If not, why does it matter if it's 50? Even if Saim is dependent, the points aren't the risk...Sally not getting done is the risk (at which point Saim could offer to help; Lean practice).

And a host of other questions. And, to fair, I'm not sure you've explored all this with the team yet, but it's not clear by the phrasing of the question.

Conclusion

When it comes to Agile Software Development, I always start with the values from the Manifesto. And, whenever someone comes to me with a question about something that falls in the "right" - I try to shift my focus to the left. In this case, the Agile Software Development value under consideration is:

individuals and interactions over processes and tools

Estimating, Planning Poker, and a host of others are, essentially, processes. Story Points, time estimates, and so on are tools. Which brings us to the left.

What interactions are you and the team trying to facilitate? How safe does the team feel with each other? What are alternatives to story points as a means of cultivating the new type of interaction? And, what's the maturity of the team when it comes to Agile Software Development (who are the individuals on the crew and where are they in their journey)?

Answer 4

I'm currently managing 7 teams that contribute to a single project. While we're one large "team", each team does their own estimates. This sounds very close to what you have -- one large team, made up of several smaller teams.

This is where your problem can be solved -- recognizing you have multiple teams. Each team should be responsible for their own estimations. If that team is 4 people or 1, it makes no difference. Each team does their own estimations (https://www.scrum.org/forum/scrum-forum/6774/how-decide-how-many-story-points-take-first-sprint).

Velocity will tell you how EACH TEAM is doing with their estimations. Ignoring the story point numbers and turning it into a ratio/percentage can give you a useable number for each team.

• Team A (1 person) estimated 21 story points and completed 21. This would be 100% or a ratio of 1:1 or simply "1".
• Team B (3 people) estimated 45 story points and completed 38. This would be 84% or a ratio of 1:.84 or simply, "0.84".
• Team C (1 person) estimated 13 story points and completed 8. This would be 62% or a ratio of 1:.62 or simply, "0.62".
• Team D (2 people) estimated 35 story points and completed 50. This would be 143% or a ratio of 1:1.43 or simply, "1.43".

The teams individually now have an idea of the accuracy of their estimations (noted in their Retrospective) and can make adjustments (or not). Doing this sprint after sprint will typically see each team get closer and closer to "1", as their estimations will be more and more accurate.

There is no need for Team A to have the same estimations as Team B.

Answer 5

Have you tried simply counting the stories/tasks/PBIs/Whatever per period of time? There have been multiple studies done that show SP estimation is only marginally more accurate. The increased accuracy is arguably not worth the extra time (and aggravation) it takes to do story point estimation. I've presented about leaning out your estimation process. (press "P" to see my notes).

You can utilize Little's Law to calculate your estimates, rather than guess at them. Paraphrased:

Avg. Cycle Time = Avg. WIP / Avg. Throughput

Answer 6

And how about not estimating at all? Just count the number of stories (each is 1) and thus discover the team's velocity. I heard promising stories based on this approach. Alternatively you could use Small (1) Medium (2) and Large (3) estimates.