A popular project management framework, Scrum, utilizes Sprint cycles to create measurable deliverables in a fixed time box.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Fundamentally, Scrum is just a project management system. It’s a system of accountability, and a structured way to get projects done.
What is a Sprint?
The heart of Scrum is a Sprint. A Sprint is a deadline, set within a period of one month, in which a team develops a usable and releasable product. This period could be one week, two weeks, three weeks, or a month—but it cannot be more than one month.
Within this timeline, a deliverable is created. The deliverable can be part of a much larger project, or it can be a project in itself. Most importantly, it has to be a deliverable.
A sprint consists of five primary parts:
- Sprint planning
- Daily Scrums
- The actual work
- Sprint Review
- Sprint Retrospective
During a Sprint:
- No changes can be made that endanger the deliverable
- The deliverable goals do not decrease
- The scope may be clarified and re-negotiated between the team, as more is learned
I’ll dig into the 5 parts of a sprint:
Sprint Planning is a maximum of 8 hours for a one month project. This plan is a collaboration of the entire team, management, and stakeholders talking about what they expect. Developers provide realistic estimates based on those expectations. The deliverable of a Sprint Planning session is what work will be done in the fixed time of the sprint. For example “We will have the home page of the website done by the end of this sprint. This will include all the pictures and the basic structure of the website. This Sprint will not include text; we will create the text for the home page in the next sprint.”
A Daily Scrum is a 15-minute event for the Development team to plan the work for the next 24 hours, address objections, and inspect progress towards the goal.
At Jay Nine, Incorporated, our sprint meetings usually answer “What did you do yesterday?” “What are you doing in the next 24 hours?” and “Do you have any questions or objections?”
The Daily Scrum is an internal meeting where non-development members are not invited because it risks becoming too disruptive.
This accounts for the actual work done on the project, the development of the deliverable.
The Sprint Review is a meeting held at the end of a Sprint. During the Sprint Review, the team and stakeholders collaborate on what was created in the last sprint. The “next steps” are planned during this meeting, and the primary purpose is to review what occurred (both good and bad) in the last sprint, and what’s next.
The Sprint Retrospective is a chance for the team to inspect itself and create a plan for improvements for the next sprint. The Sprint Retrospective occurs after the Sprint Review and before the next planning session. This is a positive, productive, non-judgemental meeting where “room-for-improvement” issues are addressed and laid out. In a month-long sprint, the meeting is time capped at 3 hours.
Why Does a Sprint Work?
A lot of companies don’t realize that you can’t have both of these in a project:
- Perfect predictability
- Unlimted/quick response to changes
The fundamental of a Sprint is that it has a fixed scope and deliverable.
This is not the norm for projects. In a lot of projects, you’ll sit down and plan or set deadlines that are six months out or more. You have done a brief amount of planning, and want to get going. As the project unfolds, new ideas creep up. Management or development starts adding little tasks that take 1 – 2 weeks at a time. A few tasks that “should only take a few hours” end up “taking a few days.”
The issue here is that you end up three months down the road expecting to be 50% done with the project. Instead, as a result of all the changes and unpredictability, you’re 10% done with the project. The project cost is in danger of crossing the budget, and there’s a lot of features that were “nice to haves” that are now part of the core release.
Having a fixed, unchanged, deliverable and a fixed timeline helps get things done faster. Little “hey I need to bounce a few ideas off of you” are saved for planning meetings — after the current work has been completed. It leaves no room for egos or change in direction, as there is a fixed deliverable that needs to be met.
Starting with Sprints
A team doesn’t have to do full Scrum to benefit from sprints. I encourage companies to utilize this in non-tech projects too. Here’s my suggestion:
- Have a meeting to discuss what exactly will be done on this project in one week. Confirm with the people building it that this is realistic and can be done in one week (even if it’s just a small part of the project).
- During this period, allow for no changes in the scope. If the project is off track by day 2 or 3, or doesn’t make sense for the business, cancel this sprint and repeat step #1.
- Meet on this every day. Even if it’s just a brief email check-in (which is ideal, as it uses the least amount of time)
- In the end, conduct another meeting to see what was done, what’s next, what can be done better
It’s incredible how, after a month of 4 sprints, you realize that more is accomplished in a one month period with fixed deliverables, than a three month period without fixed deliverables.