Today, we’re announcing our new pricing structure, which is called Agile Contracting. And it’s how we’ll be running projects going forward.
Agile Contracting is a newer term in the industry, so its meaning can vary a bit. But here’s what it means to us:
We believe that clients should be motivated financially to manage scope and budget. And that we should be motivated financially to manage the efficiency of our software process. Traditional models are backwards, with the software company acting as the scope manager or the client trying to keep engineers working in the most efficient way possible.
We intend to turn those traditional models upside down with Agile Contracting. Clients will now pay weekly for a team to complete User Stories on their projects. Each week, the client gets a set number of EduPoints to “purchase” User Stories that the software engineers work on.
The client is able to make informed decisions about changing scope, because they know that it may add to the project’s timeframe (and thus, affect budget). And we are motivated to keep our teams operating as efficiently as possible, because we are committing to moving a certain amount of work through our process. If we get behind, our client doesn’t pay for catch-up time.
Rather than pitting the client against the company, Agile Contracting seeks to have each party managing things they are especially equipped to manage. Our contracts use a system in which you pay for throughput of EduPoints.
At EduSource, the first thing we recommend is an exhaustive Discovery Phase. Coming out of it, we’ll break your project into specific features, which will then be broken down further into User Stories.
Each of these User Stories will be given an EduPoint value, depending on its complexity.
When you pay for a team at EduSource, you choose a rate that you want EduPoints to be “spent.” Each week, you’ll meet with your Client Relationship Manager (CRM) to prioritize remaining stories and make sure we understand the acceptance criteria (basically, how will you know if we have completed the story?). The team will then start working on the stories, completing them within the next three weeks. When they’re complete, you’ll have a week to test them out, then we’ll consider them done. In the meantime, you keep choosing the next body of work for your team.
We love that we can form a true partnership with our clients, instead of constantly hounding them about new scope. When we’re well into a project and a client has a great new idea, we are happy to break down the associated EduPoints and shift course. And we love that our clients let us be the experts about how we write software.
Change priority or add scope – it doesn’t matter to us, as long as you are comfortable with the changes to your budget.
You get an allotted number of EduPoints, which you use to “purchase” User Stories for development. The number of EduPoints you get depends on which Project Mode you’re developing in. User Stories are broken into a size based on complexity. Each size has a corresponding EduPoint value.
Nope, that’s not how EduPoints work. Each User Story is made up of a set amount of EduPoints, depending on its complexity. Stories range in size from small (which takes only about a day to develop) to large (which takes more than a week). That’s where the breakdown of points comes in.
The meeting can be in person or by phone, whatever fits best in your schedule. You’ll meet with your CRM to decide what new User Stories should be next in line for development. There will be some restrictions (like two larges is never a good idea), but your CRM will be able to help you with these choices.
The answer to that is “usually.” Of course, it depends on what resources are available in the office. We can generally work this out, but just to be sure, try to plan as far ahead as possible. If you know you’ll have a larger weekly budget available in a month, let us know as soon as you know, so we can plan.
Keep in mind that we do have a special plan called Summer Hustle Mode, which really ramps things up, going to a weekly rate of 61 EduPoints instead of the 33 in Hustle Mode. If you really want to ramp things up, summer can be a great time to do so.
It won’t always. For instance, you might decide that next in line should be two small User Stories and a medium, but there’s no extra-small handy to round this out.
Don’t worry – we’re looking for an average of points. Some weeks your CRM will have you pick more than your allotted points and some weeks less. She will help you walk through this process to ensure that your queue will work for the development team.
More than 95% of the time, selected User Stories will be completed and ready for you to test them within 3 weeks. Some of them will be finished as early as the next week. As a company, we use sophisticated metrics to ensure that we are on track. But if we get too far behind, we’ll let you take a week off your payment schedule, and we’ll get caught up.
A bug is when your system doesn’t work according to the agreed-upon acceptance criteria. We’re talking functionality here. If the system isn’t functional, that’s a bug. If the system works as designed, but once you see it you would like it to work differently, that’s not a bug (but it also isn’t a problem). This change will be added as a new User Story (likely an extra small one), and you’ll add it to the queue when it makes sense.
It depends on how and when we catch it. If we find it during our testing or you catch it during User Acceptance Testing (UAT), we will fix it as part of that story. If you’ve already signed off on the story and it is considered done, we will log a new User Story to fix the bug.
Each week in your replenishment meeting, your CRM will demo new functionality to you. At this point, you’ll have a week to play with the new stuff, using it in every way you can think of, and report back to us. Any bugs you find will be fixed at this point. Tweaks you want made will be added as new User Stories.
No, we use a Kanban methodology, which is more about getting stories finished than starting new ones. Each week, your team will pull some of the User Stories you’ve chosen into slots for development. From there, your team will assign work and complete the software process for each story. When they complete stories and have availability, they’ll try to help finish current in-progress stories, then they’ll start work on a new story. Sometimes they’ll get ahead of their EduPoint rate, so your CRM will help you plan out some extra stories, just in case.
Because we use apprentices for some of our work. We hire computer science university students during their junior and senior years to work for us. They go through extensive training to be ready to serve right on our development teams, along with our full-time software engineers. Our teams are in contact with these students daily, assigning them work that they complete around their class schedules.