Get certified - Transform your world of work today

Close

When Backlog Items Are Finished Too Early

What do we do if the team works faster than expected?

15 September 2015


When we take on a fixed-price project, we have an initial backlog (on which we made estimations) that can, of course, change over time. This potential change can lead to a completely different software product from what was agreed to at the beginning of the project life cycle. I'll use my experience as a starting point for discussion.
 

Faster development of backlog items

This time something new happened: We finished our backlog items before the negotiated fixed date in the contract. We finished work in six sprints instead of eight. That's good.

What did we do with the remaining time? Exactly what the customer expected us to do: We accepted more backlog items in order to fill the void in the remaining sprints. Stakeholders were delighted because they got what they wanted, on time, and even got more functionality that they hadn't thought about during the first few sprints.

This led to new problems I didn't even consider.
 

Margins on the project

In my company, and in many others, annual income depends on the margins on every project. The question I was asked: "Why didn't you stop as soon as you completed the backlog items? Remaining sprints could have been seen as project margins. This way, you did not get any margin improvement with respect to what had been planned, so don't expect any bonus at the end of the year."

OK, I can live with that; I know that, too often, margins are reached through unpaid overtime. But the question remains on the table: What do we do if the team works faster than expected?

With a fixed-price contract, time and scope are also fixed. We stop thinking in terms of customer satisfaction, and that is not what I want.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 3.7 (3 ratings)

Comments

Arun Chinnaraju, CSM,CSPO, 9/17/2015 5:56:23 PM
Giuseppe,
Thanks for sharing your experience.

My 2 cents based on my experience both a project manager and scrum master.
1. Doing more than what was initially committed to is considered Gold Plating and something that should be avoided.
2. Customer might expect the same next time and will also have doubts about the team’s capabilities to estimate realistically.
Kapil Goel, CSP,CSM, 9/17/2015 9:34:17 PM
Thanks for sharing the real time experience.

"With a fixed-price contract, time and scope are also fixed. We stop thinking in terms of customer satisfaction, and that is not what I want."

From the write-up it looks like, customer got satisfied when team finished the work in 6 sprints.

My further inputs -
1. For high quality release, we can ask customer to do thorough UAT and can do sprint hardening for next 1-2 sprints

Also the team, which not yet adopted in Continuous Delivery, can focus on undone work like transition, KT, User manual etc etc (Beyond DoD agreed)

2. Team can focus on removing Technical Debts (if any)

Cheers
Kapil
Lucas Smith, CSP,CSM,CSPO, 9/22/2015 10:31:53 AM
This is a situation i have been in all too often as well, and one i admittedly have not had great success addressing. I have heard a couple good ideas on how to address this that i am continuing to push on though.

1) Structure contracts to encourage collaboration and mutual benefit for finishing required work early. one thought would be to have a contract clause that allows the customer to accept the product early at any point and recover say 80% of the remaining cost that you have not incurred (The remaining 20% becomes additional profit margin for the company). This encourages the customer to be clear about true need (not trying to squeeze the most out of you on a fixed price contract), and focuses the company on meeting the customers needs as well to increase their margin.

2) Work on your pipeline of work. This is one of the most challenging for us as if PMs and Management think that if a project "ends early" - what are they going to have employees work on? Having a robust backlog of work, and not rushing to start work instantly helps a lot with this (but can be difficult to get senior management to buy into)

3) Keep a clearly maintained backlog with all feature requests from the customer in priority order. If you are getting close to completing the "required" functionality, and your customer likes what you have been delivering and sees all the cool stuff that they would love to have on the backlog - it definitely encourages follow-on contracts and work.
Giuseppe Decandia, CSP,CSM,CSPO, 9/27/2015 11:42:43 AM
Thanks all for your suggestions, they're all valuable to me.
I'll soon commit on @Kapil suggestions about doing something more on KT, manuals and so on.
What I want to try to do is devoting "spare time" to training as well. Something like hack days widely used in Spotify.
Going back on Lucas suggestion on contracts, I was wondering if we could use a terminology like "Fixed Time Maximum Price".
That way, in my opinion, it would be very transparent to both parts.
Thanks again

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe