It is a common misconception that if you follow Agile/Scrum then giving a (fixed) sales quote for your clients is impossible or at least very hard due to the "fact" that they more or less neglect project planning or at least do not care much about them.

The only promise of Agile/Scrum is "we'll work as fast as we can and we will see how much you will pay at the end".

Well, first of all, let me convince you about the foolishness of this theory very quickly.

If you read my article about what Agile and Scrum actually areit should obvious to you at first glance that Agile is not against responsible planning, not against fixed price.
Actually Agile has nothing to do with these topics directly. Reading the Agile Manifesto it is quite clear for any careful reader.

Regarding Scrum... it is a framework without too much concrete things to say. So again, what does it have to do with fixed price quotes or careful and responsible planning? Nothing. You are right.

So let's assume that I have convinced you.

So if somebody claims that Agile/Scrum is against planning and giving fixed price quotes he actually claims no more than that it is not possible plan a project within the boundaries of the 12 principles or that few things Scrum tells in his humbleness. It would be so sad if it was true because those principles and the framework itself all look pretty sexy don't they (here is your last encouragement to actually read them)?

Well, fortunately it is not true.

What is true however that driven by those principles and the elements of the framework we plan our projects differently and therefore we give price quotes differently compared to the "classic" approaches.

Does it mean that these new ways of planning would be worse? Why would they be? Do you think Agile principles are worse then "classic" ones? Hopefully not. So it should be easy for you to accept that planning methods deducted from those principles are not worse either.

Let's see what you need for a fixed price quote?

• Good understanding of your client's business needs (scope, deadlines, etc)
• Gathering estimations from your team
• Calculating feature and project price
  • Cost price (how much the development of the product will cost you)
    • Risk analysis (how certain you are about the cost price)
  • Profit rate (if you need profit, we do because money makes us happy(ier))
• Contracting

Actually these questions are to be answered no matter what kind of project you run, "classic" or Agile.

Let's see some ideas how we can handle these in Agile. Actually it is how we do that within Moresimp, and they work for us.
Do they not work for you? Let us know, we can share our experiences, and maybe we can help.

• Understanding client's business needs

This very first step seems obvious but according to our experiences sometimes neglected or at least not taken seriously enough.

From the very first meeting it is crucial that you should try to understand what your client needs, not what they say they need!

It may seem that we do not treat our clients as adults and we want to tell them what they need.
No, that is not true at all, our clients are adult and very successful in they own fields and are treated as such with full respect.

BUT they are not from IT so they speak different language, they have different vocabulary, different understanding of IT expressions.
Many times they ask you for X only because they think that X is the best IT solution for their business problem.

But keep in mind that they are NOT from IT, so it is very probable that X is a bad solution or not a solution at all or there is better among the ones you know.

You are not in the Army, you serve your client best if you ask back and try to find out what the business problem is rather than following orders blindly and covering your ass with a contract afterwards.

Rule of thumb:

Never accept a requirement until you understand a business problem it solves.
Sometimes it can be as trivial as "we need Oracle database because we have 10 Oracle licenses for 10 years for 10 million dollars". It is a completely OK argument. But "because i said that" is an argument of idiots.

"Client is always right"... regarding their business goals! An intelligent client will love you for this attitude.

If you keep asking back, after a few minutes they give up using their IT vocabulary, and start using their native business language.

And it is your goal, speaking in business terms, since you must understand their business anyway in order to provide them a solution they need, but they do not have to and should not have to become IT engineers to make your life easier.

The result of this discussion should be a requirement specification draft (short sentences, in a TXT file or any note application during the meeting) that clarifies roughly items like these
(we use this list as a non-comprehensive reminder)

• business goals of the projects
  • what is it in 2 sentences?
  • what is its goal in 2 sentences?
    • if money, then how do they want money from it?
  • distinguishing features
  • target audience
  • milestones
    • business goal
    • deadline (with reasoning)
• our team's responsibility (Development/Desing/QA? partly? all?)
• real-life use-case-s in written form (this way the client has to really think about them)
• integration with other projects, parts of the project
  • involved partners
  • integration points
• features (in use-case or even Story form)
  • all ideas should be listed (ideas clearly only for the future can also help to reveal hidden business needs), prioritization is for the future
  • do not forget to ask "why?" for all features
  • do not go on until you understand what the given feature is for, and until you can imagine how it would work
• non-functional requirements
  • look&feel (design style, basics)
  • usability/accessibility
  • restrictions on used technologies
  • legal restrictions/requirements
  • development methodology/tool/environment restrictions (revision control, CI, client infrastructure, etc.)
  • production environment
  • performance
    • speed, latency
    • capacity
    • scale-ability
    • availability
  • security
    • authentication/authorization
    • channel security
    • data/database security, backup
    • audit logging
    • application logging
  • i18n
  • data/business logic migration from existing system(s)
  • adherence to standards (like ISO standards)
  • documentation needs
• QA
  • scope (support OSs, browsers, devices, etc)
  • manual, automated tests, measuring coverage
• Processes during development
  • Explain how we work
  • Who will be the PO? (it may reveal that they can't give one which always a big risk)
• Afterlife
  • Support/bugfixing needs
  • Handover to internal development team
  • Future business plans

Based on this draft your team should be able to create a requirements specification. This is NOT the 300+ pages requirement specification of Waterfall when you write it to become the part of the contract covering your ass.

Its only purpose is to ensure that you and your client are on the same page regarding to goals, features and other, non-functional requirements.

Therefore you must write it in plain English avoiding unexplained IT terms and expressions with the following main sections

• Glossary
  • VERY important, establishes a common language
  • DO NOT explain IT terms, instead clarify terms used with a special meaning within the application (like "user", or "record") to avoid misunderstandings
• Proposed architecture with technologies (only 2-3 pages with big, easy-to-understand pictures and with the descriptions of each module, plain explanations)
• Features (in Story-like form making them immediately understandable by anyone who understands the business goals)
  • think about grouping them together (let's call them Epics, Themes, whatever you want, basically feature groups)
• Non-functional requirements
  
  

Send this requirement specification to your client and talk(!!!) about it. If they answer to your mail "fine", they just did not read it, it is very dangerous(!!!), always make them read but at least read them together. Rest assured there will be misunderstandings in it, guaranteed!

After you both agree on that you are on the same page regarding the requirements, it is time to create a one page summary that gives your team a high level overview about the features where you can estimate quickly with your team.
Previously we used an Excel table for that (well, a Google Spreadsheet) but since we invented Plangle our lives have changed, and it cures psoriasis as well... of course.

Why did we not use JIRA Agile for that? Because we found it very hard to estimate Stories without seeing their description and sub-tasks on the same page, that's all.

• Gathering estimations from your team

Well, well, our favorite topic since it is among the ones people can die for proving that their approach is actually the right one (btw. what do you think about AMD and NVidia cards?).

We have our opinion as well, but it matters a little eventually (no worries, we have got used to that, Hungary is a little country),
what does matter actually is that whether your methods have served you well until now. Are you satisfied with them? If your answer is yes, there you go, just go on with them.

However you may want to read this comparison, it may give you new ideas.

Before we start this discussion, we strongly recommend you watching this great material from Master Cohn on the topic.

After watching this video you should have a pretty clear picture on how and why Agile estimation and tracking (should) work.

However in practice we have seen different practices as well. We are fine with them as long as they help your project to be agile.

Let's see a quick comparison of the approaches we have met until now.

• Mike's approach, plus some thoughts from us

As you could see in the video this approach separates project planning/tracking and tracking of progress within Sprints

• Project planning and tracking

For project planning purposes it suggests your team should estimate ALL the Stories in Story Points when the project starts. Practically Story Points are actually relative weights, a Story with 2 Story Points means that it takes 2 times more time for team together to finish this Story than to finish a Story with 1 Story Point. And means nothing more!

You can use Planning Poker to give these estimation and there are other techniques but we found them too childish for our own purposes while we see their benefits.

Your results should look something like this.

Ok, and what about project tracking and predictions about the future?
If you take Agile principles seriously, the only measure of progress you can accept is that how many Stories are completed in a Sprint. If you add up the Story Points of these completed Stories you have your team's velocity for that Sprint, easy enough isn't it? You can use this velocity (and your own experiences/judgement) to predict the progress of your team for the future.

That means that during your Sprint you must focus on completing as many Stories as it is possible. Do not cheat! There are no half-complete Stories! Why? Have you met a developer who said "It's 95% percent ready boss", and he kept saying it for 3 days? That's why.

• Sprint progress tracking

We can use velocity to predict our progress for the future, but how can we track our progress within a Sprint? Why do we even need it in the first place? Well, you do not need it. It is just motivating to see how we progress compared to what we estimated.

To track our progress within a Sprint we split the Stories of the Sprint (usually in the Sprint planning meeting) to sub-tasks that covers the scope of the whole Stories. We usually use hours for sub-task estimations. Why? Because we would like to see if a task takes more time than we estimated. If it happens day-by-day then we probably won't complete some Stories at the end of the Sprint or we have to change something to meet the Sprint goal (for instance add more resources to the project).
To build trust it is always good to communicate our failure to our own commitment to the Sprint goal as soon as possible. Or you can add more resources, or handle the situation.

Long story short, tracking your Sprint day-by-day gives you a hint about your progress and let you to handle the situation accordingly.

Once you set the "Original estimate" field of the sub-task to the estimation, you can use JIRA's worklog feature or more sophisticated solutions like the Tempo Timesheets plugin to record the hours spent on these sub-tasks.

JIRA Agile's burndown chart gives you a good overview on how your overall progress within the Sprint based on these sub-task estimations.

In Plangle you can give estimations to your sub-tasks pretty quickly.

• Story estimation = Sum of sub-task estimations

We have seen (and used) a modification of the approach above which says that you should use the sum of the sub-task estimation as your Stories' estimation. Please note that it does not mean that you should estimate your Stories in hours? What holds you back deriving your Story Points from the sum of the sub-task estimations?

It's a tempting solution which works pretty fine as long as you always split ALL your Stories into sub-tasks and ALWAYS use the sum of their estimation as the estimation of your Stories.

Story 1 - 24 (story point)

•  Subtask 11 - 8h
•  Subtask 12 - 16h 

Story 2 - 8 (story point)

•  Subtask 21 - 2h
•  Subtask 22 - 6h 

 
It may look weird that you add up hours and get Story Points. But again, Story Points (and any other Story measures you choose) are just relative Story weights, nothing more. So does it hurt if you (consistently) derive those weights from the estimation of the sub-tasks? After all this way you can get a finer grade Story Point, can't you?

Anyway, if you like this approach we have good news, Plangle has support for it.

You can copy sub-task estimations with a click, or even make it automated.

• Story estimation = Sum of sub-task remaining estimations

We have seen (but never tried) an approach where somebody wanted to make his Story estimations ALWAYS equal to the sum of the actual remaining estimations of their sub-tasks.

If you think about it a bit, it means that with this solution you believe that if you team says that "It's 95% done" then it is true.

While we think it's not an Agile approach (and you'll disappointed) we are considering supporting this type of Story estimation as well.

• Calculating feature and project price

At this point you have estimated Stories (with estimation sub-task or not, depending on your chose approach to estimate Stories) that look something like this

But you still need to have prices for each Stories (so that your client can see its prices) and for the whole project.

To calculate these prices basically you have to consider (just like in any other projects)

• Cost price (the price the feature/project costs you)
• Risks (you need proper risk analysis that can hugely affect your prices)
• Profit (if you need)

Cost price or risk calculation are quite common general PM practices, no matter if you follow the Agile principles or not so we do not want to discuss them here, only the differences.
The main difference regarding cost calculation in comparison with non-Agile projects is how we predict in Agile projects the finishing date of a project or a feature (Story). Of course this prediction directly affects our cost prices.

Regarding profit, we do not need it in Agile projects. That's for old school guys. We need huge profit!

• How to calculate feature/project price in Agile projects?

This question is covered thoroughly in the documentation of our "Planner" feature-set so please take your time and read it.

As a quick summary we can say that you should

• calculate how many Sprints you'll need to complete the project based on
  • historical data (from previous Sprints, or even projects, but this latter should be avoided due to its unreliability)
  • input from your team (ask them how many Stories they could complete in a Sprint, picking up stories from the beginning, middle and end of the project equally)
• calculate the average team price for a Sprint (for the future)
  • cost price 
    • considering the availability of each team members for the project
    • the cost of each team members
  • risks
  • profit
• remaining project cost = remaining number of Sprints * cost of the team for the remaining Sprints
• redo these calculations after each Sprints so that you always have an up-to-date forecast
• since you have the weight of your Stories (in Story Points or whatever measure you chose) you can quite easily calculate the cost of each Stories as well. BUT please remember that these cost calculations for your Stories are just as reliable as the relative estimation of your Stories.

Why is this approach better than a Gantt-chart?

• calculations considers all the information you have BUT no more
  • your team's past performance (past velocity)
  • your team's commitment for the future (velocity commitment for the future)
    • they consider all the factors (possible work parallelizations, pitfalls they know about, etc.)... well, at least they can consider more than a Project Manager can.
  • your own judgment for the future velocity (based on how much you trust in your team's velocity estimations you can and you should always do a sanity check)

Think about it, can you have more, more precise predictions about the future? Do you have more data to draw more or better conclusions? We think no.

• Risk analysis in Agile projects

The project/feature price can be hugely affected by other factors, let's call them risks.

There are huge sections of great many books about risk analysis/handling/mitigation in Agile (an non-Agile) projects, you may want to read the corresponding section of this one about the topic for instance.

To give you an idea about the basics here we present you a short checklist on what kind of risks you should definitely consider (and try to mitigate) before giving a final price quote.

• Risk of scope misunderstandings --> Scope misunderstanding buffer

No matter how hard you try, no matter how long your requirement documentation is, you'll face with the fact during the development that you and your client misunderstood each other when you discussed a feature. It is inevitable. So the only question is how to handle it.

You can deal with it

• using a T&M contract - this type if contracting is clearly the best-fit for Agile projects (see how to convince your clients to sign this type of contract in the next section) (we used it and it worked)
• using fixed priced contract
  • hundreds of pages of requirements documentation - won't work (used and failed)
  • you should apply a multiplier (usually around 20%, the concrete amount depends on how well-defined and simple the project is, but NEVER go below 15%!) in your prices that will cover this risk (we used it and it worked)
  • In Plangle we just add this "buffer" to the "Team cost". So if your cost price for a Sprint is 100$ we enter 120$ in case of fixed priced contracts.

using more exotic contract types (we never tried them, but all sound interesting)

• Risk of under/over estimations - Schedule buffers

Let's assume the scope of your project is perfectly understood by both you and your client, and there are absolutely no scope changes during your project (I guess you see how ridiculously it sounds).

Still, there is a good chance that your estimations are not accurate.

Well, actually it is worth think about it a bit. What does "accurate" mean actually when we have Story points and velocities? 

It is a tricky question...?????????

• Risk of missing deadlines 

??????????

• Project specific risks (unknown technology, missing PO, IE6 support, etc.)

In a project you can face with dozens of project specific risks. 

Agile contracting

After you both agree on that you are on the same page regarding the requirements, it is time to create a one page summary that gives both parties a high level overview about the features and their costs.
Previously we used an Excel table for that (well, a Google Spreadsheet) but since we invented Plangle our lives have changed, and it cures psoriasis as well... of course.

With the requirements specification and your Plangle sheet in your hands it is easy to negotiate with your client about milestones, priorities, prices.

It is also to easy to explain what those colored zones mean.

It is generally NOT a good idea to remove any feature (Story) that makes any sense, just move them to the end of the feature list (probably to the RED zone) and that's all.

Contract types

T&M (Time & Material) contracts

I guess you have heard that Agile projects works with T&M contracts only. You heard it wrong.

We prefer T&M contracts in case of Agile projects because

• it respects the fact there will be many changes throughout the project, changes that must be administered in the contract (as well) if you do not have T&M contracts
  • new Stories
  • reordering of Stories
  • changing of Stories
• encourages the client to actively work together with us (give us a PO, participate in meetings)
• encourages us to show real and satisfying progress to the clients at the end of each Sprints
  • in case of T&M project it is very common that our client can cancel the contract at any given point of time
    
    

Fixed price contracts

Other exotic type of contracts

Contracting considerations

PO, not participating...