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?
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.
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.
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
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.
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.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
Why Executive Sponsorship Makes All the Difference on Software Projects (article)
Fractional Is Not Interim (video)
Scale Without Staffing Increases (video)
The usual causes are requirements that were never fully defined, estimates made before the work was understood, scope that grows without the schedule moving, and dependencies on people or systems outside the team. Technical surprises happen too, but they are a smaller share than planning gaps. Projects that start with a complete release plan and tracked velocity see the slip early enough to act.
Story points size work relative to other work, which is more consistent than guessing hours. Once a team has run a few sprints, its average points per sprint, the velocity, becomes a reliable forecast. Dividing the remaining points by velocity gives a completion date grounded in actual pace rather than optimism, and it updates every sprint as the numbers come in.
Say so immediately, with the numbers. Then choose among the honest options: reduce scope to the features that matter most, add people where work can be parallelized, or move the date. Working longer hours rarely recovers more than a sprint and lowers quality. The velocity math shows how far behind the project is, which makes the conversation about trade-offs rather than blame.
Yes, when the scope is defined well enough to estimate and changes are handled through a visible process. The risk sits in the definition stage, which is why thorough release planning comes first. Fixed budget and fixed date work together only when scope is the variable that absorbs surprises, which means agreeing up front which features can be deferred if needed.
Compare the share of story points completed with the share of time elapsed, and plot it each sprint as a burndown or burnup chart. If 25 percent of the time has passed and 25 percent of the points are done, the project is on track. A gap of more than one sprint is a signal to act. Sprint reviews give the client the same picture on a regular cadence.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
