Sharing backlogs with clients
I have some concerns sharing backlogs with our clients because of the level of transparency. Instead i prefer to only share a critical path release plan. I would be interested to hear your feedback and thoughts on the matter.
Here are some of my concerns.
• We bill many of our Clients based on time spent, but not everything that goes through the Sprints is billable, the Critical Path allows us to only include work which is billable
• We often end up fixing bugs and issues that the Client is not aware of. I’d rather not highlight the number of issues we get which we fix “on the quiet”
• Clients want to attribute a time cost against each task done which can be related back to a £ value. This doesn’t really work with Backlogs as points correspond to effort not time (we’ll often update the Critical Paths retrospectively with the correct amount of time)
• Some task estimates are likely to raise questions from Clients. E.g. Yellow Team velocity is 1.5, and they have estimated a text change on the site at 1 point, which rounds up to 1 day (don’t charge out work at less than a day). I wouldn’t want to show a client that we are billing them a day for a text change.
• There is a huge amount of detail in the backlogs and everything is written as a story... Ideal world, every Client would understand story writing, agile, and points estimates, but bottom line is they aren’t interested, they want Client Services to manage that bit for them. Clients prefer less detail, top level of task done, time taken, cost.
> I have some concerns sharing backlogs with our clients
> because of the level of transparency.
It's up to the Product Owner to decide how and when to share information with stakeholders. Are you the PO?
> Instead i prefer to only share a critical path release plan.
> I would be interested to hear your feedback and thoughts on
> the matter.
What purpose does a Critical Path serve with regard to your releases? In Scrum, each increment must be potentially releasable.
> • We bill many of our Clients based on time spent, but not
> everything that goes through the Sprints is billable, the
> Critical Path allows us to only include work which is billable
Why isn't everything that goes through the Sprints billable? If work provides value, and incurs a team cost, then why isn't the PO accountable for a corresponding stakeholder investment? If the work doesn't provide value, why is it being done at all?
> • We often end up fixing bugs and issues that the Client is not
> aware of. I’d rather not highlight the number of issues we get
> which we fix “on the quiet”
If you are the Product Owner, then it is up to you to manage stakeholder expectations regarding product quality. However, a PO would also be responsible for maximizing the value provided by the Development Team. Defects and rework are a type of waste, and a good PO will work with the team to reduce this.
> • Clients want to attribute a time cost against each task done
> which can be related back to a £ value. This doesn’t really work
> with Backlogs as points correspond to effort not time (we’ll
> often update the Critical Paths retrospectively with the correct
> amount of time)
In Scrum, value lies in the incremental delivery of working product. It does not lie in tasks done or in the satisfaction of a critical path longer than one Sprint.
> • Some task estimates are likely to raise questions from Clients.
> E.g. Yellow Team velocity is 1.5, and they have estimated a text
> change on the site at 1 point, which rounds up to 1 day (don’t
> charge out work at less than a day). I wouldn’t want to show a
> client that we are billing them a day for a text change.
Task estimates are provided by the Development Team for their own purposes, and no client has the right or the responsibility to question them. The purpose of estimates is to allow a Development Team to decide how much work it can take on in a Sprint. In an agile environment, this decision does not have to be explained or justified to anyone outside the team. Clients should determine whether product increments deliver sufficient value to them, and this position should be understood and represented by the PO.
> • There is a huge amount of detail in the backlogs and everything
> is written as a story... Ideal world, every Client would
> understand story writing, agile, and points estimates, but bottom
> line is they aren’t interested, they want Client Services to
> manage that bit for them. Clients prefer less detail, top level
> of task done, time taken, cost.
It is the Product Owner's responsibility to explain the Product Backlog to the relevant stakeholders. The items on it should be produced in a collaborative spirit of refinement, involving the PO (who is accountable for the associated value) and the Development Team (who are expected to understand them and subsequently do the work).