Should we estimate our tasks?

Reading your question I was wondering what these task are and why you doing them if they do not deliver direct value. Could it be that these task are basically part of your stories?

You mentioned that the main goal of your estimation is planning and velocity. If estimating these task will help the team doing there planning and/or gives them a better insight in there velocity, you know what to do.

You can also just try it out for some time, evaluate and diced how to move on.

I'm comfortable not estimating bugs, I think if we were to estimate bugs then we would inflate the amount of value we could deliver in our velocity

That's interesting. I would suggest that until those bugs are fixed velocity may well be zero. Velocity is the rate at which work is Done.

Furthermore, if that undone work is not estimated, the Product Backlog will not be telling the truth about how much work remains for the Product.

What has got me scratching my head is whether we should estimate our tasks

What do the Developers think? Estimation has nothing to do with value and everything to do with how much work they think they can take on in a Sprint. Whether their work is expressed as tasks, user stories, tickets, foobars or a combination thereof is immaterial.

Strictly speaking, if the Developers can eyeball the amount of work for a Sprint and say "that's about right", we should demand no more from them than that. If their forecast is good, everything else may then be reduced to the value actually being delivered and to empirical process control.

The only important opinion is that of the team. Estimates, if the team chooses to use them, are best used by the team in order to plan their Sprint. Estimates aren't for use by stakeholders outside of the team. So if the team feels that certain things need to be estimated or certain estimation techniques best help them, then that is what the team should try. Iterative and incremental approaches to development, like Scrum, give the team the opportunity to experiment with changes to their way of working and not necessarily commit to changes for a long time, so if someone on the team has a better idea, the team can decide to try it for a Sprint or two and see how their behaviors and performance are affected.

Looking at this particular scenario, I do have some thoughts.

I don't understand the hesitation to estimate bugs and tasks. In Scrum, there are only Product Backlog Items. Each Product Backlog Item represents something that is needed to improve the product. Although it could be useful to think about different types of Product Backlog Items, I can't think of a reason why they would be treated differently in terms of how the team puts them through the workflow, which would include estimation. One case where I could think of would be if a bug is found before a Product Backlog Item is delivered - this is really undone work and not a defect in the product, so it wouldn't become a Product Backlog Item until the undone work was delivered and a Product Backlog Item would represent the need to finish the work.

I'm also not clear on why tasks that don't provide value would be anywhere. If the work is something that is needed to improve the product, it would be a Product Backlog Item. If it's on the Product Backlog, then it should be able to be expressed as something valuable to some stakeholder, otherwise there's no point in doing the work and it should be removed. Other work may appear on the Sprint Backlog to help the team understand everything going on within the Sprint and to make appropriate plans, but some work may not exist on the Sprint Backlog either. There are plenty of things that people do in the work day - reading and responding to emails, taking company training, helping colleagues on other teams - that don't go on the Product Backlog and aren't necessarily needed on the Sprint Backlog.

Scrum is not a project management or time management system.  It is a framework that enables teams dealing with complex and changing problems to enable feedback loops that will lead to iterative incremental delivery of value.  The Product Backlog is expected to contain items defining all of the work that is needed to increase the value of a product.  It is not supposed to be a place where all work that a team does is found.  For example, you do not put items that represent lunch, vacation, meetings, updating timesheets, installing updates to work computers.  You only list items that are product related. 

A Product Backlog does not contain bugs, tasks, stories, requirements.  It contains items to identify work that needs to be done to a product.  If your organization chooses to distinguish between the items, that is entirely up to you but the same rules apply for all of those item types. This is why I advocate that everything be entered as the same item type. When you use different types, people want to treat them differently.  Having only 1 item type makes it easier to treat everything equally.

I also want to point out that everything your team does is estimated.  It may not be formally recorded in a field in your system and is instead kept in the heads of individuals but it is estimated.  In my lifetime, I have never met a human being that will start work on something without some kind of estimate.  There is nothing in the Scrum Guide that says an estimate has to be recorded.  In fact the word "estimate" is not used in the current version of the Scrum Guide. 

How your team decides to deal with item types is entirely up to them.  However, what items are present in the Product Backlog is something that you, as Scrum Master, can and should influence as your responsibility to the organization to understand the Scrum framework.

Stories, bugs and tasks do not exist in Scrum. Are these all Product Backlog Items?



If they are all PBIs, and you estimate PBIs, why not all of them? Often the reasoning for not estimating some of the work is not velocity, but because "velocity should be representative".



But customers don't actually care about any of that, what they care about is what value is provided, and the Sprint Goals can be better for that. So, care about it if it helps the team estimating the Sprint Backlog or if it helps for the Daily Scrum. Otherwise, meh.

Thanks so much for all your very useful responses, I should have made it clearer what tasks are defined as. Simple tasks such as adding a user to a system or doing a security upgrade, important stuff but not directly related to the build. I can see now that separating stories and tasks by whether they add direct or indirect value is not much use. I think Tjeed was right, the tasks are part of our stories.

I also haven’t been paying much attention to done and undone work up to now, so I need to look more closely at that, especially whether our bugs are done/undone, I suspect a mixture of both.

The Engineers are keen to estimate everything because it feels right to them, so I guess this is a good enough reason to do it and of course iterate and improve over time.