It is a common misconception that if you follow Agile/Scrum then giving a (fixed) price quote for your clients is impossible or at least very hard due to the “fact” that Agile/Scrum 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 are it should be 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 principles of Agile it is quite clear for any careful reader.

Regarding Scrum… it is a framework without too many 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.

Let’s see what you need for a fixed price quote in an Agile Project

• Solid understanding of the framework you are working with: Agile Price Quote: Step 0 – Poor Vocabulary, Poor Conclusions, Poor Decisions
• Good understanding and record of your client’s business needs (scope, deadlines, etc): this article
• Gathering estimations from your team: coming soon
• Calculating feature and project price: coming soon
• Agile contracting: coming soon
• Meeting your contract: coming soon

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

Let’s discuss some ideas about how we can handle these in Agile. Actually this is how we do things within Moresimp where they indeed work for us.

Do they not work for you? Let us know, we can share our experiences, and maybe we can help.

Understanding the 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 tell you 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 adults and very successful in their own fields and are treated as such with full respect.

BUT they are not in IT so they speak a 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 in IT, so it is very probable that X is a bad solution or not a solution at all or there is a better one among the ones you know.

You are not in the Army, you serve your client’s best interest if you ask follow-up questions and try to find out what the business problem is rather than following orders blindly and covering your rear end with a contract afterwards.

Rule of Thumb:

Never accept a task until you understand the 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 the “because I said so” is an argument of idiots.

“The client is always right”… regarding their business goals! An intelligent client will respect you for this.

If you keep asking follow-up questions, 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 similar application during the meeting) that clarifies roughly items like these
(we use this list as a non-comprehensive general checklist)

• 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 these projects
  • 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/tools/environment restrictions (revision control, CI, client infrastructure, etc.)
  • production environment
  • performance
    • speed, latency
    • capacity
    • scalability
    • 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 and 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 part of the contract covering your rear end.

A requirements specification’s only purpose is to ensure that you and your client are on the same page regarding 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 probably 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 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 on the features where you can estimate quickly with your team.

Previously we used an Excel table for that (well, a Google Spreadsheet) with its obvious pros and cons.
Then we tried JIRA Agile but we found it very hard to estimate Stories without seeing their descriptions and sub-tasks on the same page.
But since we invented Plangle our lives have changed, and it cures psoriasis as well… of course.