Adding estimation points for learning / context switching

Question

In our scrum team, team members tend to add extra points in estimation when there is a "learning" part involved.

Here's a simple silly example. Let's say all the people in a team are experts in C# but with less knowledge of C++. They have a task to implement feature X in C# and they estimate it to 5 points. If they would be asked to implement the exact same thing in C++ estimation would be let's say 8, because they added some points to figure out how to do it in C++.

In our team it happens sometimes that for each task a couple of people didn't work in that area of code (as we ore owners of more than 1 project) so they always add a couple of extra points for learning or for context-switching (if they didn't work in that area for a longer period) when estimating. Is this correct?

Do you add learning in your estimations?

Thanks

Answer 1

• Story Point is used for high level planning. When we estimate User Story in Story Points we talk about productivity of whole team.

• Points stories is not for exact measurement, story point is for relative measurement. While we using Story Points, we can talk that this Story is bigger or harder than another Story, but we can't be sure how much exact time we will implement it.

For example: You have 2 User Stories. Them Scopes are approximately equal to each other. But one of them should be implemented on C# and another on C++. Your team have two C++ developers and only one C# developer. So, of course User Story with C# implementation will be more harder for your team and, obviously, it should be estimated with more Story Points.

Answer 2

i think that adding points for context-switching is not a good way of estimating. i mean, the task itself will not be more complex by this. as far as i see, this is a very typical case of padding the estimation - intentionally giving larger values to reduce stress or time pressure later.

the problem of this approach is that estimates will be falsified, and the measurements will be less precise. a better way would be not adding complexity for task switching, but have a lower velocity measured, and maybe the cost of context switching can be added to impediments.

(as for the learning, i agree with the previous comments - if you need to learn something new in order to produce results, it makes the task more complex)

Answer 3

Story points are a relative measure of complexity. They add up to create a velocity that can be used to determine the AVERAGE workload a team can take in an iteration. If a story requires additional learning by the team, it is more complex and can be estimated higher. Story points are a team measure, not an individual measure. Don't fall into the trap of taking the lowest estimate and then assigning the work to the person that estimated it low. Try and build a team that follows a pull model instead of a push model so that team members gain experience across all domains in the project and are empowered to decide what to work on. Short-term this may hurt "productivity" but long term will create a team with broad domain knowledge, higher productivity, and less risk of hitting major technical barriers.

If you have 1 developer that needs learning and 1 that doesn't you will get two individual estimates that need to be combined to form the team estimate. In this case, I recommend you go with the higher estimate since the worse case scenario with the higher estimate is that the work gets completed sooner by the experienced developer and something else can be pulled into the iteration.

Whereas if you go with the lower estimate and the un-experienced developer ends up doing the story your team just over-committed and you set un-realistic expectations for your customer that iteration.

Answer 4

The short answer is no, skill differences between developers are accounted for using velocity and should not impact story point estimation. It is easy to confuse the Scrum concepts of points and velocity since people are often trained to estimate in units of time (e.g. "I'll be done by Thursday"). In Scrum, estimates are made using units of size (e.g. "The race is 100 meters"). Team velocity is measured by observing how many points a team is able to repeatedly complete during a sprint (e.g. "The athlete runs 5 meters per second"). As velocity improves with skill or process changes, delivery dates are calculated (e.g. "It will likely take 100/5 = 20 seconds to finish the race").

Estimating Points

Try using the planning poker method for estimating stories. This will resolve the issue you're running into where two team members call the task a "3" while another team member calls the task an "8". What you want is consensus across all team members. You'll notice three key steps in the planning poker procedure:

1. The team members with the lowest and highest estimates each explain their reasoning to the rest of the team.
2. After hearing the rationale for the high and low estimates, team members vote again.
3. This process is repeated until all team members reach a consensus.

Estimating Velocity

Use velocity to account for the different skill levels of the members on your team. Remember, the story point value is not an estimate of time, but rather an estimate of distance. It is okay, and expected, that different members of your team will be able to sprint that distance at different speeds. To estimate velocity, maintain a running average of points completed in each sprint. Use the team's velocity value to decide how many stories can be completed in a single sprint. This capacity limit will account for the fact that different team members write code at different speeds (e.g. that some need to learn more than others, etc.).

Answer 5

Yes, we do.

You estimate the effort of a story. If you break down to story to different tasks, you'll have for the C++ story learning as additional task.

Nevertheless, the product owner assigns the same customer value to the C++ and C# story. During the sprint planning, the team should prioritise the C# story due to the same value but less effort.

Answer 6

You will always get different estimates from different people for a variety of reasons. You just need a simple way of reducing it down to a single number for planning purposes.

I have found just taking the average to be a good method of achieving this. Your high and low estimates will give you an idea of the uncertainty of the estimate.

Trying to dig down and split the estimate into sub tasks of 'learning' or 'context switching' can be counter productive and usually just increases the estimate and the uncertianty

Answer 7

Some historical data should already give you an idea of whether this +2 points is somehow accurate or not. Did you already measure this?

In these cases I usually advise the team to split the learning activity from the production one. Learning will be done in one sprint, estimates and production in the next one. Unless you're talking about trivial stuff, adding a buffer is unlikely to give you any accuracy on whether it is actually going to be 20% or 30% or 50% more, and indeed C++ and C# are two very different languages... if they don't know how to do this stuff in C++ it might be as easy as C# or way more complex.