A complete beginners guide to Agile Methodology

Agile methodology has been around for some time now, and is widely adopted by teams creating software, but there are still a lot of people for whom it’s a bit of a black art. This guide is designed to give a total beginner to Agile enough info to understand the basic principles and terms that are used. It’s not meant to be a full comprehensive guide or anything close to it, but it’s got enough info so that if you are part of an Agile team you can understand how things work.

What is Agile?

Agile is a system designed to enable the following results:

1. Rapidly create stable, working software that is responsive to business needs.
2. Reduce developer burnout and create a comfortable working environment over a longer period.

The Agile Team

Agile teams are relatively small cross-functional teams of between 6–12 people, which usually contain the following:

Stakeholders: anyone who has an interest in actually using or selling the software. This may be any combination of clients, a sales agents, a Business Development manager etc. Not actually part of the Agile team, but the Stakeholders are effectively who the team is working for.

Product Owner: the interface between the Stakeholders and the rest of the team. The Product Owner’s main responsibilities are:

1. Talking with Stakeholders to understand their needs, and turn those needs into User Stories for the rest of the team.
2. Adding User Stories to the Backlog, and continually updating and organising that Backlog so that the team have a good understanding of what is required from them.

The Product Owner is very definitely a part of the team, not their boss!

Agile Coach (optional): the person whose job it is to keep the team focused on Agile principles and keep the ball rolling through the Sprint cycle. In smaller teams this is often the same person as the Product Owner.

Developers: this can be anything from coders to UI/UX specialists, to graphic designers etc. Basically the people making the software. They usually make up the bulk of the team.

QA (optional): Depending on the size of the team, Quality Assurance people may be part of the team, or may work in an associated team. If you’re working in a small startup with less than 6 developers then you’ll probably have your QA people as part of your team. Conversely if you have a team with 12 coders, UI/UX etc. you’ll want QA in a different team.

The Elements of Agile

Backlog

The Backlog is the list of all the User Stories, Tasks, Bug reports etc. that aren’t being actively worked on in the current Sprint. The Backlog is normally organised using an Agile project management software application such as Jira, Trello, Taiga etc. that the entire team have access to. The Product Owner continually goes through the Backlog and prioritises it with the most important things at the top and less important things at the bottom.

User Stories

A User Story is a business requirement stated in a single sentence in a specific form. This sentence contains the Who, the What, and the Why of the task. It’s always written as:

As a [type of user], I want to [achieve a specific result] so that [I can fulfil a specific need]

For example:

As a person who has just woken up this morning, I want a cup of coffee so that my brain can function better

The User Story serves two purposes:

1. It sets out the requirements that the team need to turn into development tasks.
2. It can be used by the Product Owner and QA personnel to validate that the software developed is not only functional but also meets stakeholder needs.

Tasks

Tasks are specific actions that need to be taken in order to fulfil User Stories. For example, for the User Story:

As a person who has just woken up this morning, I want a cup of coffee so that my brain can function better

the Tasks might be:

1. Go to coffee shop
2. Show credit card
3. Drink coffee

Story Points

Developers are traditionally terrible at estimating the amount of time something will take to develop. But we still require a method of judging how complex a User Story, Task, or Bug might be, so that when we are planning a new Sprint we can figure how much work the team should be able to achieve during the Sprint cycle. For this we use Story Points, which are a relative measure of the complexity of any development task. For example, a very simple bug fix might be given a Story Point value of 1, a slightly more complicated piece of programming might have a Story Point value of 2, and so on. Note that the more complex a task is, the harder it is to estimate precisely how difficult it might be, so Story Points tend to be assigned something like:

1, 2, 3, 5, 7, 10, 15, 20, 30

Anything that has a Story Point value of over 20 may be too complex to fit into the Sprint and might need to be broken down into simpler tasks.

The team should keep track each Sprint of how many Story Points worth of work they are achieving during the cycle so that when the next Sprint Planning meeting happens they can more accurately estimate what tasks can be achieved.

Issue Status

We need to have some way of measuring progress on each issue during a Sprint. The simplest system has 3 stages:

1. To Do
2. In Progress
3. Done

Items are marked To Do when they haven’t not been worked on, In Progress when someone is working on them, and Done when the task is completed.

However for cross-functional teams this might be too simple. If your team contains QA people for example, you might use a more advanced system that contains Status options for the QA process:

1. To Do (not yet started)
2. In Progress (being worked on by a developer or UI/UX person)
3. QA Ready (development task completed but needs to be tested)
4. QA Done (issue tested and passed)
5. Done (see below for Definition of Done)

It can be tempting to add more and more Status options to your workflow, but it’s usually not a good idea to make it much more complicated than this.

Definition of Done

You might think that knowing when something is Done would be the easiest thing in the world, but in the world of continuous software development it’s not that simple. It’s important for a team to discuss together what exactly “Done” means for them.

For example, if your team doesn’t have QA people in it, then Done for the team might mean “Finished coding and sent to the QA department”. However if your team does have QA people in it, Done might mean “QA checked and passed, and new code running successfully on the Staging server”.

What is a Sprint ?

A Sprint is basically a time-boxed period within which development occurs.

How long is a Sprint?

Most Sprints are, on average, 2 weeks long; however in some cases it might be as short as 1 week, or as long as 4 weeks. How do you decide how long your Sprint should be?

1. All tasks that are assigned at the beginning of the Sprint should be able to be finished by the end of the Sprint. If an individual task would take longer than your Sprint cycle, then you either need to break down your task into smaller sub tasks or you need to make your Sprint cycle longer.
2. At the end of the Sprint cycle there should be a Work Product created that is reviewable by the business Stakeholders. By getting fast feedback from Stakeholders at the end of each Sprint we can ensure that our software not only works technically, but also fulfils customer needs. If you can’t produce a reviewable Work Product at the end of your Sprint, your Sprint is too short. Note that the Work Product does not have to be actual working software, it can be UI design, concept art, etc., but there has to be something that the Stakeholders can access, understand, and comment on.

The Sprint Cycle

Each Sprint has certain formal meetings and events that take place each and every Sprint:

1. Before each Sprint Cycle starts, the Product Owner meets with the Stakeholders to find out what business requirements the team need to work towards in the new Sprint. The PO will also collect feedback from the Stakeholders on the latest Work Product to validate that the team are creating software that works the way the Stakeholders expect.
2. The Product Owner turns the Stakeholder requirements into formal User Stories and adds them to the Backlog of tasks for the team; and collects any bug reports or usability concerns that the Stakeholders might have based on the previous Sprint’s Work Product. The PO then prioritises the tasks in the Backlog based on business requirements. The PO may also set a Sprint Goal for the upcoming Sprint.
3. On the first day of the Sprint, the team meet together to go through the Product Backlog of tasks, starting from the top of the Backlog and working their way down. They examine the User Stories, turn them into actionable Tasks, and assign a Story Point value to each ticket. Once that’s done, they decide which Tasks can be tackled in this Sprint, based on what the business needs are, and on the complexity of each task. Anything which can’t be done during this Sprint will be left in the Product Backlog to be dealt with in a future Sprint. This may be quite a long meeting (in my experience it’s usually 1–2 hours long), but by the end of it everyone on the team should know what is expected to be achieved during this Sprint. Once this meeting is over, the Sprint officially begins.
4. Each day of the Sprint, the team meets for a Standup. This is a short meeting, about 10–20 minutes long, where each member of the team answers 3 questions:
   What do you do yesterday?
   What do you plan on doing today?
   Is there anything blocking you that you need help with?
5. At the end of the Sprint it’s normal to hold a Sprint Review, where the team go through the work of Sprint and examine what went well, what was problematic, what might be improved etc.
6. A Work Product is created and given to the Stakeholders to play with so they can review and validate the work.

Conclusion

Thanks for reading my very brief guide to Agile. There’s a lot left out, but this should be enough to get you going if it’s your first time working within an Agile team. Feel free to leave comments if something isn’t clear, or you think I need to add something.

Happy developing!