Should the incidences of continuous improvement, Spikes and delivery be estimated, based on agility?

[Lina Marcela Almanza P_]

Hi,

I hace the next question:

Should the incidences of continuous improvement, Spikes and delivery be estimated? 

These incidents require effort, but I would like to know what is the best practice.

I appreciate your help!!!

Lina A.

[Earl McCutcheon]

Hi @Lina Marcela Almanza P_ ,

Thanks for reaching out to the community, and this is a good question but also really hard to answer as this blog post sums it up really well in the first line:

• Story points and estimation 

Estimation is hard. For software developers, it's among the most difficult — if not the most difficult — aspects of the job.

Best practices in estimation are to start off loose and tighten up the numbers as you figure out what works best, and how the team operates over a few sprints.  And realistically experimentation while watching the outcomes is going to be the best approach to find out what works best for defining your team's workload. 

Currently, If you are including the inflated estimates to compensate for spikes, or delays and are constantly coming in way under the deadline, the best approach is to reign in the estimates to a tighter estimate value so you can add in additional workload knowing that the team will make the deadline under those tighter estimates.  However in juxt position, if you are not including those options for some additional leeway but are constantly running into scope creep and delays in releases due to unforeseen blockers or underestimating, then the opposite is true and you will want to start giving the estimates a bit more breathing room.

Along with the blog post mentioned above, I also recommend checking out "How to choose the best methods of estimation for planning" as well.

Regards,
Earl