Real cost of a PBI / feature
Hello
After a normal poker planning evaluation of several PBIs that are part of a specific feature that our team has been asked to develop for a client, we were able to translate the numbers and give a cost estimate for the feature to that client and he has agreed to that evaluation.
However, we are also asked to provide the real costs of implementing the feature, because the organization where I work usually charges the real costs to the client, which at some point makes sense. In Scrum, since we're not tracking the "real" time spent on each PBI, how do you come up with the right numbers?
Of course, if we were only working on these PBIs in a sprint, it could make things somewhat easier to calculate, but we are not. We have a bunch of not necessarily related PBIs that are also part of the sprint.
I would much prefer sticking with the planned evaluation if the PBIs for that feature are all DONE at the end of the sprint, but I also understand the "honest" way of thinking of my organization when billing the true costs to the client.
I'd appreciate any insight!
Thanks
Scrum provides for an iterative and incremental means of delivery. That implies funding should be incremental, and costs should be per Sprint. It is up to the client (or more precisely, the Product Owner) to determine if the Return on Investment is adequate and further Sprints at that cost are justified. Essentially clients should pay for the incremental reduction of risk, the demonstration of success being the ongoing delivery of value, increment by increment, for a known price per increment.
In Scrum you should not attempt to map costs to story points. As Ken Schwaber (the co-founder of Scrum) has said, the only purpose of estimation in Scrum is for a team to be able to "get its arms around" how much work it thinks it can do in a given Sprint.
If this is too revolutionary a funding model for your client, you could try making a best-guess estimate for the final cost. If you know the price to charge for each Sprint, you can then work out how many Sprints can be funded. Although the final costs might be fixed, the scope would be variable and the client (through the Product Owner) would determine the delivery goals on a sprint-by-sprint basis. This is not as agile as true incremental funding, but it is often the most practical approach.
I agree with Ian if your client is buying whole sprints worth of work, etc, but it sounded like from your context that this was just a lone feature kind of thing. If so...
I would say that his has nothing to do with Scrum. If you want to bill your client for time and materials, then have each person who participates in it log time to it, including all meetings where the entire team is present and the feature is discussed. I think that's an incredibly inefficient and ineffective way to do it, though, and should have absolutely nothing to do with Scrum.
If it was me, after the Sprint, I'd ask my team -- "You guys estimated this at an 8 -- did it feel like an 8 when you did it? If not, what did it feel like?" -- then I'd do
(estimated *actual* cost in story points)/ (story points completed in the sprint) * cost of team for a sprint
and charge that to the client with the appropriate markup.
Now, if you do *all* your work that way, then I would make sure I was MUCH more careful to separate this exercise from Scrum and disclaimer disclaimer disclaimer it as it has nothing to do with Scrum-- but I would still probably use the same approach.
Yes, that calculation would be a good way to pro-rata the cost of a feature per sprint.
Ok, that's a good suggestion I guess.
I know all about this not being Scrum at all, but at the same time, we've got reality to live with. The organization I currently work for is still in its infancy in regards to Scrum (and Agile in a whole) and my team and I (which I am coaching) are leagues beyond its traditional thinking and approach.
We are nearing the end of project development and we will soon fall into maintenance and evolution of the application, which will then be handled by another team, hopefuly with some Scrumban approach where time spent on each request is often better registered...
The project in itself is a great success and the first to be completed using Scrum and we are proud of that fact. Management quickly understood the benefits and is very happy with the results. However, I now feel like the management responsible for maintenance and evolution is still "old-fashion" and will need convincing too. Their budget being spread across several applications, they need to more closely follow costs of the changes and bill the clients accordingly. I believe a good Scumban approach will better server them now.
So I guess we're just in-between phases...
Thanks for the suggestion!
For the record, I do not believe in Kanban or Scrumban for software development. I would probably recommend Scrum with 1 week sprints, one backlog with all supported products on it, and emergencies handled as follows:
http://scrumcrazy.com/bugs
Also, for the record, I don't believe in handing off software to maintenance teams. I believe in software teams supporting their own software and "eating their own dog food" -- because it encourages good habits long term which are better for the company generally speaking.
OTOH, I don't look down on your approach either, so please don't take this as an insult -- just stating my opinions.
Charles,
Funny you should mention that.
I went to a seminar where Mary Poppendieck was presenting a session and that's one story she told.
Cant remember if it was HP, the team that delivered the software was responsible for 30 days post launch.
Prior to this it was handed straight off to maintenance, who had hell every time from customers.
It wasn't long before the software became far superior in quality after the teams had to support it.
360 experience turned things round dramatically and the rest they say is history.
Michael