We Code in the Context of our Quoting

9 min readMar 16, 2017

This article can be listened too here or in your favorite podcast player

Whether you are working Waterfall, or Agile we still need to quote out the time it will take for new features. We still need to give the product owners, or the people with the money, a sense of timing. And it is this skill or lack thereof that drives the experience we are going to have when we code.

There are many, many, many formulas around on how to quote and how not to quote. And I am not talking about **Fixed Bids** here those are a story in an of themselves. I am talking about sprint planning, task planning anything that is part of the relationship between you and the owner to have a sense of how much something might cost.

And it is this skill or lack there of that drives experience we are going to have when we code

In this article I will cover two main concepts. One is about pacing yourself for the “race” ahead. Every task/feature or whatever is like a little, or big, jog. If you start the jog not knowing how long it is then you have no clue how to pace yourself. And if you have no idea where you are in the “track” or race then you have no clue if you should speed up or slow down. So to begin with we need to consider how to quote items. Second I will cover how to know where I am in the race.

Be warned I suck at spreadsheets. I use them to their bare minimum but that is for me enough to make all the difference in my day to day work

Who is this article for

It is for developers who find themselves not working in the ideal Agile situation and maybe still in Waterfall. Where Story Points are not an option and the client need a sense of time a feature might take so they can budget for it. This is not for Fixed bids. Sure it can work for that but those always are risky and may take different tools.

This is also for developers who know quoting sucks, who know things go wrong and this “technique” will help to, sooner than later, check in with the client so they and you can have a good sense of how things are really going.

Thoughts on Quoting

And above all remember, you are not building features you are building an application, so with each new feature you are responsible for the bigger picture or health of your application.

Story points are an interesting practice BUT I find it hard to use them most of the time with clients. It seems a bit too abstract. Sure there might be a client who really get’s Story points but this article is more about that middle ground, where you want to write good code in the context of a client who is confident in the time “range” you quote for the feature.

I am going to share some spreadsheets, but be warned I suck at spreadsheets. I use them to their bare minimum but that is for me enough to make all the difference in my day to day work.

The first “tool” is here basically I am doing two things. A simple Quoting template with ideas from the book “Agile Estimating and Planning” no offense to them if I got it totally wrong.

First I will write out all the tasks that make this feature. And second I will write down assumptions so I make sure they are presented to the client as well.

Keep in mind this is not quoting out an entire project. Sure you can do that but I will focus on a feature. Some of which might take a week or two weeks or maybe less.

This sheet will take your items and instead of buffering each item it will buffer the results and add them to the total of the columns you quoted at 60% confidence to hopefully end up with a more realistic result. I will cover Confidence levels in a moment.

And as the book “Agile Estimating and Planning”; which I link to below, notes if you buffer each item then you are going to end up with too high of a quote, so that is why we use this formula.

The book uses a really simple example of having to do 5 things in the morning before going to the airport. If you buffer all 5 things then you will end up in the airport way too early. But with this approach you end up with a better buffer.

Confidence Level

To begin with I consider confidence levels. Have I done this before, has it been done before, etc. Then I quote at two levels. 60% confidence and 90% confidence.

It is these two numbers that help us make the final “buffered” results.

What to consider in this thinking? This is what at my job, we call a “Done Done” list.

* Testing
* Documentation
* Time to model out ideas
* Feedback
* Continuous Integration
* Manual QA
* Deployment

Seriously give yourself time to do these things right!

And above all remember, you are not building a features you are building an application, so with each new feature you are responsible for the bigger picture or health of your application.

Take time to consider what else this feature might be touching that needs to be fixed, tightened up or just made better. Should you include all of these little touches in your conversation with the client? In my opinion no, I think you are responsible for so much that already does not always get brought up in conversations that this falls in that area. For example maybe you know testing is weak because you had to rush the last feature, well add a few more tests while doing this feature. I think that this type of detail work goes beyond any todo list and is just the nature of being an artisan building and maintaining such a complex system.

Remember in the end if your buffer is too big or too small it leaves you in an unprofessional situation. As a professional I want to have a sense of honesty with the client that I am not over quoting items so I can sit around on Facebook or over compensate for my lack of skill in quoting. And that I am not under quoting forcing myself into a situation where I am not able to deliver a quality product and not enjoy quality coding time.

It is key to keep each item in this sheet under one day. I will cover that shortly.

Ticket System Numbers
You will notice in my sheet a column for “Ticket System Numbers”. This number I will use in the sheet that helps me pace myself. It is not a perfect number but it is a flexible formula (I change as needed) so the total matches the total that comes from the overall buffer the system makes for me. I could maybe make it a bit more dynamic and relative to the spread of each item related to the 60% and 90% quote but in the mean time I just adjust the multiplier as needed till the total matches the “Total Days” that system originally totaled up for me. Not ideals but just to help me pace myself in the bigger picture of the total time quoted.

Assumptions

Before I move on to “Pacing Yourself” I want to note this area of the sheet.
This is very important. The hardest part of our job is not coding but communicating with other humans, especially those who we are trying to comprehend what it is they want us to build.

The hardest part of our job is not coding but communicating with other humans, especially those who we are trying to comprehend what it is they want us to build

So write them out, no matter how dumb they might sound and review them with the client to make sure you are both assuming the same things.

Pacing Yourself

Human nature, in my opinion, when we do not know the length of the course we are on, is too start off too slow and end off in a desperate pace when finally we see the finish line and realize it is too late.

The client approved your numbers now it is time to start the project. Ah the first few days, so nice, so easy to relax, write a test, go for a jog, code slowly, chit chat on Slack but then it happens! You finally see there is a week left in the project, you can finally see the due date outside the abstraction of gantt charts or a ticket system, and you finally see you have a ton more work to do, and you start to run really, really fast, do not sleep, eat, do not test, do not QA or do anything but code hoping to get to the finish line.

For me this very simple system showed me how I can easily start and manage my pace. Not only that but help me to see when I am falling behind as early as possible, so I can talk to the client and let them know up front what is happening. It is a lot nicer for them to see 2 weeks before the deadline versus 2 days before the deadline how the project is really going.

I hated when managers asked me how are things going as if I could stick my thumb in the air to measure the wind and tell them “Yup things are great project is on time”

The simple stupid spread sheet can be seen here the broken site explaining it is here by Joel Wenzel

And let’s keep it simple stupid by following a few key rules.

One, who cares if you are 1/2 way done or 75% done or 90% done, it is just not done. So an item is either Complete or not. And until it is Complete do not consider it as a task done. Once Complete then add that day to the section where you total up the work you did for that day.

Second, check in the morning and see how to pace your day. It is a great way to start.

Third, you will not make up time! So do not start behind, and once you fall behind talk sooner than later to the client. It might be hard to admit you are falling behind but do it.

Fourth, one day tops per quoted item. No item can be more than a day, why? Cause you will fool yourself and if an item is say 2 days long and on the 3rd day you finally admit to yourself you fell behind then now you are possibly 2–3 more days behind than you think. Where if you had it at one day then by the next day’s morning check in you would know that you are not done and falling behind.

That really is it for this, keep it simple, check in daily and keep the tasks small.

Spikes

Quoting is hard. I mean how do you quote things you have never done before! Sometimes a Spike is a great way to just say to the client, I am not sure how long this will take, let me take 1–2 days to take a stab at it, paid days of course, and then let’s see what comes from that. If anything you will have a sense of how possible the task is and in what timeframe. In a Spike you can set aside some of the detail work and just code away knowing the code will be thrown out once done. You are mainly just trying to get an idea of how and if this task is possible.

Well, that is it! I just wanted to share these simple tools and concepts that I think are really key to **coding in the context of less stressful expectations** and therefore giving your self space to code well and happily.