Sprints: Agile Development Process

What is agile development?

Having an agile development process refers to a methodology that guides the software development process. It is both a set of recommendations and a way to build a product, making it an approach in both senses. For anyone unfamiliar with the term in a development context, it means what it sounds like.

An agile process allows a business to be flexible and make necessary changes quickly and easily, to constantly assess progress and re-examine priorities at each stage of the process.

One of the most critical components of an agile development process that has broad implications for any business is the ability to work in sprints. These are short, usually 2-week blocks of time in which a well-defined set of tasks are completed. Here’s some information about how that works.

Working with Sprints in the Agile Development Process

A sprint has a clear goal and a well-defined timeline. In the development process, this is usually two weeks. Each sprint starts with items you add to a to-do list and has a degree of comparative difficulty so the team can get a sense of how long each will take without trying to define an exact timeframe- which is often tricky regarding software development.

Throughout the sprint, the team works only on the items you have put into the task list- this helps prevent distractions that can interrupt time and make the process more unpredictable.

Sprints are beneficial in several ways. First, they provide a regular check-in for the team. In a sprint, a scheduled time when you can review and discuss work and re-examine priorities. Next, they allow a client or group to examine a functioning product regularly. In the agile model, the team usually develops work in “slices.” Where slices refer to the completion of a specific feature that can be shown.

The Agile Sprint Meeting(s)

The nature of the sprint meeting is essential to the process.

First, you’ll need to task someone with keeping the product’s vision. There should only be one vision keeper, or “product owner,” to prevent confusion in the item debate. If there is a team behind a client project, they should designate one person as a product owner. If it’s an internal project, only one person should be able to review and determine priorities. This also prevents a “too many cooks in the kitchen” problem.

This meeting is two meetings in one. You can split up the two but often condense them to save time. The first meeting is the sprint review meeting; this is a meeting to look at what the team did in the sprint and to check items off the to-do list. If the project is a client project, this is a chance for the client to approve the work.

After that, the second meeting is a sprint planning meeting. In that meeting, a team looks at the total number of tasks on the list. Then adds anything new that needs to be added and prioritizes tasks for the coming sprint.

Alternative to the Agile Development Process

There are a couple of alternatives to the Agile methodology, but most of our clients are familiar with Waterfall.

This is an older method of development where the team introduces and agrees on all requirements at the project’s onset with milestone deliverables over a long period. When you meet milestones, there’s little change or adjustments to the final product. That is without having a significant cost increase to the client. Therefore, we recommend the agile methodology over the waterfall methodology on most projects.

If you’re interested in applying a similar method in your own company, consider contacting us at Grata to help consult on how this process can best be implemented. Grata consults with companies on technology processes to improve current methods and consider tech-driven alternatives.