Complicated capacity estimation

How many products are there, and does each have a clear Product Backlog and a Product Owner accountable for value?

Bear in mind that velocity is the rate at which useful work on a product is Done.

I'm sorry, I should have mentioned that we're using scrum to manage work on a municipal program, not for software development. So while we don't have "products" per say, we have four projects within the program.

At the program level we have a backlog of tasks, but not a "product owner". Each advisor is more or less responsible for identifying, estimating, and planning/scheduling their tasks by sprint (at both the program and project levels.)

I've calculated "ideal days" completed at the program-level, per advisor per sprint, for the last three months. I'd simply like to be able to give the advisors a better idea of their capacity, because they pretty much always plan more work than they accomplish. However, it's the project-level component that's puzzling me.

So the advisors calculate the "ideal days". Do they have any input from the people that are actually doing the work? Without that I would find it very difficult to trust any of the estimates.  Also, it means that you are trying to calculate the ability to complete work based upon a guess from someone that is not doing the work.  Would you expect that to be in the least bit accurate?

As for products.  This is a statement from the current Scrum Guide

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

I would venture a guess that you could identify products in your work based upon that definition.  

I do not mean to offend you but I am going to ask if you have read the Scrum Guide.  Where did you get your information on the Scrum framework?  It seems like you might be trying to use it as a project management tool rather than a framework to help teams incrementally solve complex problems.

The advisors are estimating the ideal days it takes to complete their own work. Yesterday my manager suggested that perhaps advisors could estimate ideal days to be worked on project-level tasks per sprint, and we could use that to better estimate capacity in the future.

You're right, sorry - we're trying to deliver a variety of new services to citizens, so in that case I guess it's true that we have products.

No worries - I have read the Scrum Guide, and in my last job I worked for an organization that used a more by-the-book scrum framework, but I inherited this odd setup from my predecessor. But I will read the Scrum Guide again and see if it gives me any ideas.

Thanks, Ian and Daniel!

Sierra, I want to understand your situation better - also because yours is a non-IT application of Scrum.

What I think I understood:

• You are concerned about the time that can be spent on program level, so this is your "product".
• Your advisors are the Developers in Scrum language.
• If your advisors come together in a Sprint Planning, they should have an idea of what's the time they have to spend on their projects and what's the amount of time they can spend on items of the Product Backlog of your program. Does the team (the advisors together with you) define a Sprint Goal? I'd expect that with a very rigorously ordered Product Backlog as an input - and the Sprint Goal  in mind - they should be able to understand a) what they are able to deliver within a Sprint and b) callibrate the priorities of projects and program accordingly. - Maybe not immediately, but inspecting and adapting should lead to improvements.
• What is your task in this constellation? Are you a kind of "traditional" manager or are you more a Scrum Master/Product Owner type of person in this set-up?

I'm going to suggest that you look at these books by Daniel S. Vacanti.  The books present a set of metrics that can be used to help teams become more predictable and then how to use that predictability to forecast future work.  It might help your team find something else that could work for you. 

https://actionableagile.com/resources/publications/

Hi Oliver! 

• I'm concerned about the time that can be spent at both product- and project-level (overall team capacity). The advisors currently don't estimate their project-level work, therefore I have very little visibility into the amount of work completed at the project-level. But on the other hand, we don't want to report on project-level work during ceremonies because the advisors are all working on separate projects  that are of no concern to the other advisors. 
• "If your advisors come together in a Sprint Planning, they should have an idea of what's the time they have to spend on their projects and what's the amount of time they can spend on items of the Product Backlog of your program." - Very true, and I actually think this might be a key component of the issue. I doubt the advisors consider the amount of time required for project-level work before coming to sprint planning, and I'll make sure that changes.
• We haven't defined a sprint goal, but that's a great point, and I'll make sure we implement that as well!
• My role is Scrum Master in this setup.

Thanks, and thanks Daniel for the book recommendations!