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?
1. Thorough Release Planning
We’ve written ad nauseum 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 that it is best for both us and the customer to know exactly what we’re getting into before we agree upon 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 now are able to come up with a comprehensive list of features that are clearly defined, and consequently we know how long the project is going to take and how many resources it’s going to take.
2. Writing User Stories Correctly
We have a detailed explanation of writing user stories at out 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 system like 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.
3. Managing Scrum Velocity
This is in the final section of the Agile Resource Center’s section on Agile Release Planning, and it talks about how we are able to quickly build software without the need for 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
4. 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 to be 1000 story points, and we do a gut-check 25% through the project, then we would expect to have 250 story points completed. If we only have, say 200 story points completed, then we may need to add resources (at our own expense) in order to hit our guarantee date.
Summary
So, in summary, we are able to reliably hit our deadlines because we do a good job of release planning, writing user stories, managing scrum velocity, and periodically tracking whether or not 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 was able to guarantee delivery dates.
Again, if you really want to get a better understanding of our approach to Agile, please visit our Agile Resource Center or contact us if you have any questions. We’ll be happy to help.
Christian Schraga
SVP Product
CodeStringers