The Agile methodology

Sprints are the hallmark of the Agile methodology, which is an approach to project management - and software development, specifically - that favors working in predetermined phases that are typically two-to-four weeks long. These phases, or “sprints,” have become increasingly popular in software development since the Millennium when the Agile methodology began to gain traction in earnest.

Before the Agile methodology was introduced to software development, the Waterfall method was the primary approach to project management for delivery of software to market. Waterfall - as its name suggests - favors a linear approach to working through project phases. Essentially, Waterfall is well-suited for projects where requirements for the entire project can be clearly and comprehensively defined from day one, and where there is a low risk that inputs or expectations will change before delivery.

And that’s where Agile becomes so powerful. Unlike Waterfall, Agile is, well . . . agile. Agile allows cross-functional teams to test and iterate as they work, evaluating new ideas and implementing new demands as they come. Agile is particularly well-suited for user-focused projects because it encourages responsiveness. And that human approach means that Agile - much like the people who work within it or benefit from the products created by it - is more a collection of evolving principles and goals than it is a rigid set of characteristics.

Harnessing the power of sprints

Naturally, ceremony and structure exist within Agile as they do within any approach to project management, and that’s where sprints play their important part in keeping projects on track and on time. Managed properly, sprints enhance creativity, collaboration, and resourcefulness within an Agile team, and they’ve proven an invaluable framework for facilitating development and delivery in a style that’s at once balanced and kinetic. Of course, maximizing the value of this framework includes utilizing sprints effectively, and that most often means working in two-week phases, a period that has become an overwhelmingly popular choice for sprint duration within an Agile framework, for a few key reasons.

Why are sprints two weeks long?

1. The Goldilocks principle

Goldilocks knew when something was just right. In fact, her penchant for striking the perfect balance has become so well known that entire planetary neighborhoods (including our own) now bear her name. When it comes to duration, two weeks is widely considered to be the “Goldilocks Zone” of sprints. Technically speaking, a sprint can be as short as a few days or as long as four weeks, but fortnightly phases are most popular because they seem to combine the best of both extremes. Said simply, they’re not too long, and they’re not too short.

2. We’re wired for short-term success

Human psychology can make planning ahead difficult. In fact, science has demonstrated that human beings have a tough time with long-term planning because our brains are wired to seek short-term rewards. In that sense, two-week long sprints feed into our very biology: generally, we’re more capable of setting and executing plans in the short term, than we are in the long term. And when it comes to software development and delivery, two weeks is far enough in the future to allow for ideas to evolve and take shape, but not so far into the future that any goal or objective feels out of reach. As xDesign project manager Gayle Watson explains: “Two week sprints encourage motivation and morale within the team, as everyone is dealing with manageable chunks of work that they have committed to.”

3. Feedback means more when we don’t have to wait for it

Part of Agile are retrospectives: post-sprint meetings where teams - and clients - identify what went well, what didn’t, and what’s coming up next. Frequent retrospectives allow everyone involved to get feedback quickly following a task or activity, which promotes more meaningful reflection. Weekly feedback might become burdensome or inefficient, while feedback offered every three to four weeks might not offer the same (near) real-time opportunity for thought or correction that a fortnightly feedback loop provides. According to Watson, “Two week sprints mean we catch any potential issues faster. Getting feedback at the end of every sprint helps us shape the project moving forward, and ensures that everyone is on the same page, and working toward the same goal.”

4. It’s possible to learn more, in less time

Focusing on insular tasks for a manageable amount of time is proven to increase comfort with the task and promote meaningful mental interaction with a topic. In time management, the battle-tested Pomodoro technique dictates that a person spend 25 minutes working on one single task before resting for five minutes, recording what they’ve completed, and beginning to work again. Sprints work in largely the same way: by focusing on an objective or goal for a finite amount of time, and following that period of work with a dedicated period of review, sprints promote productive learning, and encourage engagement with the task at hand.

5. Fortnightly sprints support communication and build trust

As Watson puts it, “two week-long sprints are great for creating consistency across a project, and building a good relationship with each other, and with clients.” Two week-long sprints offer teams and clients the chance to work with one another in a highly productive cadence: one that produces deliverables often enough so that a client can see progress being made, but not at such a fast rate that quality or communication is compromised. Sprints work best when everyone involved has the opportunity to timely respond to manageable changes, setbacks, or requests. A two-week sprint cadence accommodates this format, and builds group dynamic by giving team members the opportunity to meaningfully respond to reviews and questions in a governable, approachable timeframe.

Ultimately, the decision of how long a sprint should be is largely project-dependent. Myriad factors inform whether a longer or shorter sprint (or no sprints at all) is most useful for your development project. Across most projects, two week-long sprints will promote productivity, support collaboration, and enhance delivery.

To talk to an expert about what could work best for your project, get in touch.

To view current job vacancies, and find out more about a career at CreateFuture, visit our careers page.