Beginner’s Guide to the Agile Method

(This was originally published on Optimal Partners’ blog.)

The Agile method is a project management strategy used by thousands of companies and Higher Ed institutions alike. Agile projects involve continuously updating clients with working products and iterating on development throughout a series of work cycles called sprints. After a sprint, an Agile team will reevaluate their development processes to ensure that their client’s vision is carried out. Once necessary changes have been made from previous sprints, a new sprint is started and the cycle continues. While the Agile method is often used for software development, its core philosophies can be applied to almost any type of project, team, or process. In fact, this blog is developed and managed through our own form of Agile methodology.

The Agile Manifesto

Agile development has a long history, which culminated in the creation of the Agile Manifesto, a document that outlines twelve principles that each Agile project should follow:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Agile method values interaction and collaboration over extensive planning, contract negotiation and doing things “by the book.” Sometimes things change, visions evolve, and scopes require adjustment, but instead of going back to the drawing board entirely, Agile allows teams to respond to those changes quickly and efficiently to the benefit of their clients. Although it’s not a cure-all for every project that needs improvement, Agile allows teams to thrive in environments where it is difficult to estimate the duration or scope of a project.

Learn the Lingo

Like most lessons in project management, the Agile method has its own terminology to learn before starting off. Some Agile-specific phrases are more self-explanatory than others, such as the product roadmap, an overarching plan for the development of the product’s features, or sprint review, but others may require some explanation.

First, and possibly most important of all, is the story. A story describes a requirement that must be met by a team in one iterative development cycle or sprint. It should describe the needs of a specific type of user and should be simple enough to be written out in a short sentence. A standard story template would read as follows:

As a (type of user), I want to (objective), so that I can (benefit).
Example: As a user of a website, I want to view my account settings, so that I can adjust them without reaching out to the site administrator.

Those individual stories come together to represent the functionality that the team needs to deliver to complete each sprint within the project.

Stories often combine together to create what are known as epics, or more overarching goals for the project that may have to be completed over multiple sprints. In the context of the previous example, allowing users to adjust account settings would be one story within the epic of allowing users to log in and use their accounts on the website.

Once stories have been established for a project, they are divided up among the development team and prioritized into sprints. The velocity of any given sprint describes the amount of stories that are available for that sprint.

During Agile projects, working directly with your client is ideal, but is often not viable.
A specific team member, known as the Product Owner, will be responsible for representing the client’s vision in their absence, and working with the development team to ensure that their work reflects the client’s needs at all times.

Before jumping into development, an Agile team must also assign one team member to the role of Scrum Master. The Scrum Master acts not as a manager for the team, but rather as a middleman between the Product Owner/client and the developers. They ensure efficiency throughout the development process and make sure that everyone is on the same page at all times.


Agile development is all about the iterative process, where each overarching step should be returned to and reevaluated eventually. To be truly Agile you’re going to need to get rid of your one hundred page planning document and be prepared to iterate on any procedure that needs improvement to develop the best product for your client. With that in mind, we’re going to break an Agile project into six stages that individually represent iterative development cycles with vastly different durations.

It Starts With A Vision

Each project starts off with a product vision, or a planned goal for the product being developed. In Agile’s case, the product vision may change drastically over the lifespan of the project, depending largely on its scope and time frame. Once the product vision is established, the Agile team then works alongside the Product Owner to create the product roadmap.

Releasing On Time

An important part of Agile development is getting working functionality in front of the client as soon as possible. The release planning process tasks Agile teams with establishing loose deadlines for specific functionality and prioritizing development to get the most important stories in a functional state. Your team will want to return to release planning once the new releases need to be planned for. This could be at the end of every sprint or it could be every 4 months, and relies entirely on the progress and scope of your project.

On Your Mark, Get Set…

Sprints require their own planning sessions to establish what features will be developed and what each team member will be working on during that sprint. Developers should provide estimates for how long the development of each story will take during the sprint planning meeting. A sprint could last from one to four weeks, meaning that stories should be chosen not only by priority, but also by whether or not they can be finished on time. A popular tool used during these meetings is the sprint board, a visual representation of each story and the tasks needed to complete them within the time frame.

The Daily Scrum

The shortest iterative cycle in Agile is the daily scrum or stand up meeting. A scrum is a daily meeting in which the team takes approximately 15 minutes to discuss what was accomplished the day prior, what will be worked on that day, what obstacles each person is facing, and what needs to be worked on to meet daily goals. Having multiple layers of iterative development from annual reevaluations to daily stand ups allows Agile teams to react to changing requirements quickly and reprioritize to match any new goals.

Reviewing the Sprint

Once a sprint is completed and product functionality is in a working form, it’s time for the Agile team to present the resulting stories to the client. This meeting allows the client a chance to give feedback on the product in its current form, so that any concerns or additions can be accommodated in the next sprint. Depending on the specific team, an Agile project may require acceptance testing during the sprint review. Put simply, Acceptance Testing is the process of testing the product’s functionality based on the requirements set out in the product vision. Whether a team tests in between sprints or not, they should perform Acceptance Testing at the end of the project to ensure that the product meets the requirements that were initially agreed upon.

A Look Back

The end of each sprint also offers Agile teams a chance to reevaluate their development processes and learn from past mistakes during the sprint retrospective. While the sprint review is more about functional deliverables, the sprint retrospective is more concerned with adjusting procedure than dealing with specific functionality. Once the team has learned all there is to learn from their latest sprint, the cycle repeats itself until the product is finished and the client is pleased with the results.

The Cycle Continues

The Agile method may not be for everyone, and in fact, many teams aren’t able to commit themselves entirely to its methodologies, but it does offer developers the flexibility to deal with significant changes, even those late in a project. If this is the kind of process that your project could benefit from, we hope that our guide has given you enough information to at least get you started. If you’re interested in learning more about Agile development, let us know in the comments below and we’ll be glad to explore it more in-depth in a future article.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.