I recently joined a company that has started moving towards "more agile" development. I've already been product owner for an internal software project and that worked reasonably well as far as I can tell (I'm also new the role and not a developer).

However, I will soon be Product Owner for a software project that is fixed cost. We have been given requirements with enough detail so that an offer could be proposed.

The idea is to have a kick-off meeting with the customer to obtain "rough" functional design specifications. A look at the contract reveals that, at least according to whats written there, this won't be so rough after all.

I see a lot of problems coming my way. I am somewhat worried that in the end my company will expect me to work the backlog in a way so that the functionality delivered is no more than that laid down in the "rough" specification, while the customer will see no reason to stop working until resolved perfectly.

I have very little experience as Product Owner and I really want this project to go well because I like what the customer wants to achieve with the project.

How I can take advantage of the benefits that Agile development offers, under these circumstances?

SPOILER (after a couple of month into the project): As predicted by many in this thread (and kind of expected by me) it does not work so well. The problems I expected would come my way did come... Fortunately this will most likely be the first and last project that was "managed" this way. If you find yourself in a similar situation: protest, keep everything transparent so nobody will blame stuff on you, protest, ...

  • A general tip is to strongly keep the project manager triangle in mind: en.wikipedia.org/wiki/Project_management_triangle Personally it has helped me explain that it's simply not possible to do everything everyone wants and still release a quality product on time without needing extra budget and without cutting any functionality.
    – Cronax
    Commented Mar 22, 2016 at 12:58
  • Is your project fixed-schedule - is there a fixed delivery date by which you must meet the contractual obligations? How much contact will you have with the customer and how quickly will they be able to respond to questions? How much domain knowledge do you have regarding how the customer intends to use the software?
    – Thomas Owens
    Commented Mar 22, 2016 at 13:00
  • Thomas, kind of, but not so much - more importantly, the amount of developer-days is fixed. I think I will be in contact on a regular basis and am confident that they will answer questions I will have in between scheduled meetings. I have good to very good domain knowledge. I know their business on a more abstract level as well as most of the details of the processes they are using. Commented Mar 22, 2016 at 13:15
  • 2
    Rule #1: NEVER work on rough specs. Work is only done on specs signed -off by both the customer and the person in your company with relevant authority. Commented Mar 22, 2016 at 14:03
  • Okay Danny, but isn't the reality that you will ( [almost surely] (en.wikipedia.org/wiki/Almost_surely) ) NEVER know the precise requirements before you started working, so creating the documents to great detail is really a waste of time? The high level functionality is already described in the contract. Commented Mar 22, 2016 at 14:37

4 Answers 4


Scrum is an agile framework that is focused on adapting to change and delivering business value. It encourages feedback and looks to deliver what is needed, which is often not the same as what was originally planned.

Combining Scrum with a fixed price, fixed scope contract is a challenge. It can often lead to arguments between the customer and the supplier as to what is a valid change and what should be paid for as 'new' functionality.

This is particularly difficult for you as it sounds like you are not in a genuine Product Owner role as you are not able to make decisions on scope.

My recommendation would be to use a very transparent approach to your work. Ensure that all decisions on functionality are clearly described and the implications of the change are also made clear.

It would be worth doing frequent release planning. This is where you look at the velocity of the team and see how long it will take them to complete the work that is left to do. You may find that if the customer makes changes and if the team encounters technical problems that the project deadline (and project cost) change as well. The best approach is to make these changes and their impact as public as possible, so that they are discussed both by your client and by the management team in your organisation.

Some parts of Scrum can help you with making things transparent. Make sure the backlog is public and progress is clearly shown. Speak frequently with your stakeholders and ensure they are fully engaged with the project.


Agile methodology and fixed price projects doesn't go well together as by doing a fixed price delivery you will not be able to get the best benefits of doing a project in an agile manner. To quote an example, it is difficult to incorporate demo changes and business changes when you execute within fixed boundaries.

Having said that, you can still do in sprints/agile fashion with the following steps/preparations done.

  1. Make sure you understand the specs and functionality defined clearly before committing to the fixed bid.
  2. Don't leave out any open items/ambiguous items - you either include them in your fixed price delivery after considering the risk factors or leave it out.
  3. Plan your iterations and sprint goals. Sprint zero is a good phase to do this as you can club items together in sprints which might reduce the effort.(Note that this goes against the agile principles of doing "just enough" planning.)
  4. Make a list of items/functions excluded from this phase of delivery (add rough estimates if possible).
  5. Keep track of your progress and be transparent about delays and unexpected issues.
  6. Engage with the stakeholders as much as possible so that you can manage expectations effectively.
  7. Stay close to the team and make sure they understand and follow the requirements correctly. It could happen that they wander off and create unnecessary code/test data which means you lose time.
  8. Conducting Demos in this pre-defined journey is a challenge. You'd probably have to add the suggestions/changes to the backlog with a view to tackle them in the next phase rather than implementing in the next sprint. If due to any reasons (say, business value) you are asked to implement any, make sure you swap an equal weight item.
  9. Advice team to work in a much collaborate way so that scenarios are clear and this will reduce bugs and also make fixes easy and quick.
  10. Above all, it is important that you discuss the approach and constraints with the team and business/product owner and other stakeholders and get their buy-in before you start.

It feels a lot like waterfall and is less satisfying for sure, but you can plan to deliver business value every sprint and keep going!

  • This (just like Barnaby's answer) is very helpful! So I accept his answer as "official" and would like to thank you personally :) Commented Mar 30, 2016 at 8:15

Fix the scope, then fix the price. Update constantly as you progress.

Try the estimate the project in a range according to the rough spects you have. Because they are 'rough' - the cost and time estimate ranges can be relatively far apart. 10k - 20k or 3Q - 4Q of 2016.

Use iterations for development. After each iteration you will gain more knowledge about the project, and specs. Any new knowledge that might affect the cost - should be appropriately communicated. Work with the team and update estimates accordingly.

Analyze the progress and work left. Determine what is more important - delivering the product or not going over budget. Based on that balance the project out to deliver necessary results.

Two things should happen during the project, while you gain more knowledge and decrease uncertainty about requirements:

  1. You realize that it is not possible to deliver this Scope at this Cost. In which case you request budget increase and get it


  1. Cost stays the same, but you balance out the Scope to fit the budget.

Agile best practices you can use: - Iterative approach (work in Sprints); - Sprint/Release Planning; - Backlog refinement (re-prioritize work each before each Sprint, based on situation on the project). You can use Risk - Value relationship to better prioritise it; - Story Point Estimations which over time, will bring you velocity. With that you can work out and predict cost of future items you will work on from backlog. This will help you manage budget; - Keep track of any changes, estimate their impact on cost schedule; - Make the project as transparent for the Stakeholders as possible. You have to manage it in a way that they will understand "WHY" the project will cost more or take longer, if this will be the case.


I'm not sure what Agile (or any other methodology) has to do with this question.

Without a signed off spec you're shooting at a moving target. You could work on something for a while, complete it, move on to other parts and then have to retool the initial piece which may affect all the subsequent pieces.

Rule #1 in efficient software development is "NEVER work on rough specs". Work is only done on specs signed-off by both the customer and the person in your company with relevant authority.

The more detailed the spec, the faster the coding and the fewer the changes. This may surprise you, but in some companies specs tend to be declared complete! at some point. Any further changes come at an expense, as a change request.

I once worked for a contractor who won a tender at a very low price; below cost. His entire profit margin was based on change requests. His game plan was to define the spec in such a way that it seemed complete, but in reality it was missing key pieces. When the customer requested these, he was charged for them.
"What? the door doesn't have a handle?"
"Nope, it's not in the spec. Only a keyhole was specified."

Seems like your customer is working the other way; keep the spec open-ended so that anything can be included in it.

  • Working this way is proven to not deliver value to you customers. If you measure success by "on time, on budget, and on spec" then you are missing the value: standishgroup.com/sample_research Commented Mar 28, 2016 at 12:43
  • @MrHinsh - Where on that long home page you linked to can I see that you shouldn;t work on rough specs? (And I was not saying to work like that, I was pointing out how bad it was.) Commented Mar 30, 2016 at 8:07
  • "Without a signed off spec you're shooting at a moving target." <--- You are always shooting a moving target. Agility minimises the movement with smaller and quicker increments. (the Standish group unfortunately require membership to access reports) Commented Mar 30, 2016 at 13:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.