How We Guarantee On Time Delivery

As a former software company founder I can tell you that a founder’s biggest fear is not being able to get a product launched before you run out of money. When this happens, a founder loses all credibility with investors and, oftentimes, with themselves.

Consequently, when we started CodeStringers we wanted to offer a commitment that the competition doesn’t make– a guarantee that we’ll hit your budget and timeline. This ensures that your product sees the light of day and the market can ultimately decide the success of your product rather than the competence of your software development team.

So how do we do this?

Thorough Release Planning

We’ve written ad nauseam about how CodeStringers does free Agile release planning, with blog posts both last week and earlier this year. So we don’t need to get into much detail today, other than to say that we do free release planning because we feel it is best for both us and the customer to know exactly what we’re getting into before we agree on a cost and a timeline.

However, a secondary benefit of doing free release plans is that we end up doing a lot of them, and we’ve gotten damn good at it. We are now able to come up with a comprehensive, clearly defined list of features, and consequently, we know how long the project will take and how many resources it will require.

Writing User Stories Correctly

We have a detailed explanation of writing user stories at our Agile Resource Center, but the TL;DR summary is as follows:

• Before you start the scrum process, take all the features from your release plan and rewrite them as user stories. You can write them on sticky notes or in your favorite project-planning software, such as Jira.

• User stories are initially written in the format “As a … I want to … So that ”.

• From there, you go through a requirements refinement process to make sure that each story is Independent, Negotiable, Valuable, Estimable, Small, and Testable (use the acronym INVEST to remember).

• Each story should have a set of acceptance criteria so that you know when a feature is done, and you know what to test to make sure it's working properly.

• Each story’s size is estimated in “story points” instead of hours. Stories are assigned story points by Fibonacci numbers– 1,2,3,5,8,13,21, etc. according to comparable size. For example, if Story A is worth 5 points, and Story B is bigger than Story A, then Story B is worth 8 points.

Managing Scrum Velocity

This is in the final section of the Agile Resource Center’s Agile Release Planning, and it explains how we can quickly build software without excessive documentation and administration.

For those of you unfamiliar with how Agile production works, it is based around the idea of a “Sprint,” which is a small window (we use 2 weeks, but anywhere btw 1 week and a month is workable) in which the development team completes as many story points as they can within that period of time. “Complete” means that they’ve met the definition of done and the QA team has tested it to confirm.

Maximizing sprint velocity (i.e., building as much as you can in each sprint) is a bit of an art form, but it is essentially a function of:

• Doing the above steps 1 and 2 correctly

• Having a good understanding of how to best manage the development resources, i.e., who works faster, how to get the most out of each human resource

• Proper use of tools such as Jira

Do The Math

Periodically, we do a “gut check” to see if our project is progressing on time. We do that using good-old-fashioned algebra.

For example, if the total project is estimated at 1000 story points and we do a gut check 25% through the project, we would expect to have 250 story points completed. If we only have, say, 200 story points completed, we may need to add resources (at our own expense) to meet our guarantee date.

Summary

So, in summary, we reliably hit our deadlines because we do a good job of release planning, writing user stories, managing scrum velocity, and periodically tracking whether we’re on track. I realize that the aforementioned may seem obvious and simply a matter of “common sense”, but I can assure you that when I was a client, no outsourcer I ever worked with had a process like ours that could guarantee delivery dates.