Let’s charge story points!
You did it. You are finally one of these super-hip agile leaders. Your team agiles the agility out of their agile method and estimation with story points works pretty well in your refinement, estimation meeting or planning. Time to start doing something wrong! As you have moved away from time tracking towards velocity measured in story points, you moved from a fixed price per hour to a fixed price per value unit. Your story points somehow should reflect the time but also the complexity and the delivered value of a task. And hey, after some discussion with your team, they finally do.
So why don’t charge your customers story points? The short answer is: just do it. The long answer comes as expected: don’t do it inconsiderate. There is a lot more to charging story points than just taking your teams potential and dividing it by the average velocity of your last sprints.
- You need to tell your customers what story points are. Actually it seems pretty easy to understand. Once you started working agile, it became clear to you what this currency of story points mean. But it didn’t automatically become clear for your customers. It is a long journey and a huge challenge to explain story points to somebody who actually just wants a piece of working software. If you have escorted this customer for while, they would ask why there is a sudden change in how they have to pay. People are afraid of the new, thus people won’t welcome this change (that’s not agile by the way…). A special challenge will be to justify price changes of features. Where it took you two hours to build a login, it might be worth 5 story points now. Depending on the exchange rate of these two currencies, there might be a huge gap in between. Just think about a good strategy on how to introduce the value-driven model of story points after having billed by the hour for years.
- Estimate before you quote. If you want to expose the story point currency to your customers, make sure your team has already given you a real estimation on the amount of story points. Do not think “we’ve done it before like this, it might be somewhat the same…”. Depending on the heterogeneity of your projects you might be far from right. Probably wrong. If you want this kind of transparent process don’t forget to include your team from the very beginning. What you can do is to change your quotes from story points to a larger unit like shirt sizes (S, M, L, XL…). They usually represent a range of story points in which you can have a best/worst case pricing for your customer.
- Work agile not fixed price. With the shirt sizes comes a little flexibility. Nevertheless, you have to ask yourself, if the project your calculating actually fits as an agile project. Do you just translate a specification book into user stories or features to work them off iteratively? Is there a vision that needs to be sharpened along the way or is everything clear? If you said yes-no, you probably should just make a standard fixed-price quote. Vice versa, you can go ahead and might be looking at a nice project that can be worked off with your cool, new agile method.
- Be aware that estimations might be wrong. Even though your team’s estimation often works, you probably can remember the days when it totally didn’t work. When sprints failed because features hadn’t been estimated right. Don’t be blinded by those new fancy story point quotes. Estimation can be wrong. Therefore, plan it to be wrong. Make it transparent. Maybe even go for the shirt sizes and maybe even go for the larger size. You won’t have your quote broken down in real user stories anyways. Therefore let it be epics with a price range. And have a good feeling in your guts when handing over the quote to your customer. They will understand that they pay for value. At least at some point.
- You’ll be responsible for failure. The difference to standard time & material is, that you probably can’t charge your customer too much more. When your estimation was totally buttocks, you will have to carry the can for it. It’s the other way round for t&m approaches. Your customer will just have to pay whatever it takes to finish a feature. Or abort it. Maybe it’s best to find a way in between. A mixture of shirt size/story point value-based quotes and a time & material budget to be used for support and failure in estimation.
You see, there is a lot to be aware of when deciding to charge by the point, not the hour. In the long run it will be more specific and help you and your customer to prioritize a backlog together based on value. Just make sure you used your head and some common sense to think about the consequences. Until then, come back to our blog. Because you’re not agile enough!