Creating & Starting a Sprint
When a client and outsource firm are just getting to know each other, they are also developing the seeds of a very long relationship. Since development is never truly "finished", it is important to take an approach to outsourcing that considers this fact. The Mercury Platform does this through deliberate, obvious, steps in the process. The client will see exactly what is happening and feel like they are contributing to the process and have complete transparency, but also the inability to change things or interfere in other ways when development is ongoing. This all starts with creating sprints and initial "quotes" for clients.
Quotes & Initial Items/Sprints
The clients approach your firm and need a quote. You can quote them a huge project and try to deliver it to them, but over 63% of project fail to finish on time and 58% fail to meet budget. This is why we've taken another approach, an agile approach.
When clients are first on-boarded, you should create a bunch of sprints that lay out in semi-irreducible items required for the development. Some common items we've put into sprints are Terms of Service (5 hours), Complex User Login (Admin required, 80 hours), News Feed (12 hours) and so on.
Add an item on your dashboard and press enter (or ctrl+Enter to add more the one at a time). After you create enough items to give a good MVP or other first version of the software to your client, put them in sprints based on their functionality (so all login items in one sprint, the terms of service in another sprint, etc...). When this is complete, you will have a plan for making their app come to life.
Starting the Sprint
Once you have enough items to get your client's app to a point they can play with it, you can separate them into different sprints. We liked to use similar functionality, like login, connections system, and other similar items in sprints to show the true iteration that is required to develop a piece of software. We also found doing this broke it down enough that the clients were able to see the granularity of their request and make informed decisions they otherwise couldn't have without the detail.
Once a client or team member moves a sprint into the Next Up column, a button will appear that says "Start Development". This will either be green or gray. The gray version means you have incomplete item(s). You need to fill out the hours (0 is ok) and the "I want to" portion of the user story at a bare minimum. This is done so that there is at least some direction to items and more detail behind their intent when starting a sprint and only having the button green when they are all complete a great way to not have sprints start that have had overlooked items that will require a lot of conversation during an active sprint.
Another tip we have is to move the first sprint (normally a larger one like Login was used by our team) into "Next Up". This played a key role in our close rate being so high for clients at this point in the process (100%). The green button and giving them the duty of clicking it also played a role in our specs not getting changed after the sprint had started. Leaving the client to make these important button pushes is a key reason to the Mercury Platform's success making clients feel important and involved, but not have the ability to derail progress during the sprint (and/or losing faith in the team when the inevitable hiccups happen during development).
Once the sprint(s) are started, the real magic begins. In the next post, we will discuss what it is like to have an active sprint in the Mercury Platform and how it allows your clients and team members to be on the same page and not burn out.