Why The Startup Sprint Delivers Immediate Business Value
Agile development is all about delivering valuable Results early and often, in order to receive and incorporate feedback as soon as possible. Many of the Organizations we coach are convinced that it will take months before they can write any code that produces business value. Is this a reasonable fear? How do we get past this fear? How do we get a Team writing code and delivering value as quickly as possible? And how quick can that be?
Introducing the Startup Sprint
The idea for the Startup Sprint is simple, and it gets a Scrum Team up and running quickly.
- Rename a Sprint, ‘Startup Sprint.’
- Give the Startup Sprint the goal: ‘Be up and running the first day of the next Sprint.’
- Include these three Backlog Items:
- ‘Place some quality items in the Backlog.’
- ‘Create a minimal environment dedicated to the writing of Clean Code.’
- ‘Write a piece of real code, no matter how small.’
Make the Startup Sprint as short as possible. We recommend one week because it applies pressure on the Team to achieve the three Items listed above quickly and efficiently. We don’t want the Team to do any unnecessary work in order to get to that first real code written. Rather, we want the Team to understand the point of the Startup Sprint, which is to get started, but do real stuff as you start and ramp up.
What does the Team actually do in the Startup Sprint?
Since the Team has three items in the Backlog that become the Stories; Backlog Refinement and Sprint Planning can begin. The Team elaborates upon each of these three Stories to add their Agreements and Tasks. This conversation is what is really important.
The First Story
The first Story requires the Team to do some up front thinking to figure out what they’re actually trying to build. The Acceptance Criteria for this Story could be something like this:
- ‘Add at least 10 good Items to the Product Backlog that have been validated by our Stakeholders.’
- ‘For at least one of these Items, make sure it is well-defined and small enough that the Team can develop it in one day once our minimal environment is in place.’
The Second Story
The second Story is a little more straightforward and centers on how much environment is enough. The Acceptance Criteria might look something like:
- ‘Configure everybody’s machines.’
- ‘Set up a build box.’
- ‘Get the database server set up.’
- ‘Get the Team Room set up.’
The second Story could turn into an Epic, with each of these Acceptance Criteria becoming its own Story. That’s ok, as long as the Team gets a minimal and effective environment as soon as possible.
The Third Story
Finally, the third Story is really simple. The idea is that when we have a ‘real’ Story to work on and a good enough environment. We will use that environment to do the Story and have some actual Code to Review.
Delivering Immediate Business Value Is Just a Startup Sprint Away
By using the Startup Sprint effectively, your Scrum Team is better equipped to hit the ground running.
Is your Team getting bogged down in the beginning?
We’ve got training for that.
As Always, Stay Agile.