Sprints: Agile Development Process

Having an agile development process refers to a development methodology that guides the process of software development. It is both a set of recommendations and a way of thinking about building a product, an approach in both senses of the word. For anyone unfamiliar with the term in a development context, it basically means what it sounds like- the ability for a business to be flexible and to make necessary changes quickly and easily, to constantly assess progress and re-examine priorities at each stage of the process.

One of the most important components of an agile development process that has broad implications for any type of 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. At the beginning of each sprint, items are added to a to-do list and given 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 difficult when it comes to software development. Throughout the sprint the team works only on the items that have been pulled into the task list- this helps prevent distractions that can eat up time and make the process more unpredictable.

Sprints are beneficial in a number of ways- number one they provide a regular check-in for the team- a scheduled time when work can be reviewed and discussed, and priorities re-examined. Next, they are a chance for a client or team to regularly examine a functioning product. In the agile model, work is usually developed in “slices”, which refers to the completion of a specific feature that can be shown.

The Agile Sprint Meeting(s)

The nature of the sprint meeting is important to the process. First, someone has to be tasked with keeping the vision of the product being developed. There should only be one vision keeper, or “product owner” to prevent confusion and loss of time in the debate over items. 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.

Now, as for the meeting itself, it is actually two meetings in one- or the two can be split up, but they’re often condensed to save time. The first meeting is the sprint review meeting- this is a meeting to look at what was done 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. The second meeting is a sprint planning meeting. In that meeting a team looks at the total number of tasks currently on the list, adds anything new that needs to be added and prioritizes tasks for the coming sprint, pulling them onto the to do list.

Alternative to the Agile Development Process

There a couple of alternatives to the Agile methodology, but at Grata we mostly find that our clients are familiar with Waterfall. This is an older method of development where all requirements are introduced and agreed upon at the onset of the project with milestone deliverables over a long period of time. We find that when milestones are met, there’s little change or adjustments to the final product without having a significant cost increase to the client. This is why we recommend the agile methodology over the waterfall methodology on most projects.

If you’re interested in trying to apply 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 their technology processes to improve current methods and consider tech-driven alternatives.


Like the post? Share it:
Rey Ortega
Rey Ortega

I'm a passionate creator of technologies for businesses. After years of leading software teams & delivering products to market, I founded Grata Software, a software consultancy, that helps businesses innovate and build disruptive products on cloud platforms. At Grata, I am the CEO & Head Solutions Architect.