You might have heard of the Agile Development term already. So in this tutorial we like to learn what is it about exactly and how to manage a project with the best practices in mind using the Scrum technique which is a flavor of Agile.

What do we mean by Agile development?

Agile is a different approach to software development which replaces the old school Waterfall software development process.

In Waterfall you would consider the whole project at the beginning and do the following step by step: Analyze, design, code and test.
Each of these steps should be completely done before you proceed to the next one. But the problem with this process is that when a change happens at the middle of the project then you will face huge problems, as you didn’t have any plans for it!

In Agile development you first define different pieces for your project and then do all the steps mentioned in the Waterfall process for each piece.
Agile methods use an iterative approach to a project with tight feedback loops that enable rapid adaptation when a new information or requirement for the project becomes available.

In simple terms, you are agile! And instead of predicting the whole project requirements right at the beginning, like how you do it in the Waterfall process, you are an adapter and accept the fact that change may happen! So as an adapter you adapt yourself along the way as the project is moving forward.

What is Scrum?

Scrum is one of the most popular agile techniques.
It was first introduced by Hirotaka Takeuchi and Ikujiro Nonaka in their ground-breaking paper “The New New Product Development Game” which has been published in the Harvard Business Review in 1986. Since then Scrum has been codified by Jeff Sutherland and Ken Schwaber and they have published the first official paper defining Scrum named “SCRUM Software Development Process” in 1995.

It’s easy to get started with, and features professional training and recognized certification.

Why do we need scrum?

First let’s just mention some of the problems that the traditional Waterfall project development process has:

• Teams work completely independent from each other and each sub-team completes its own activities before the other one starts its own. So what is the problem? An issue on one team, blocks the whole production line!

• Everything is decided up-front! So what is the problem? Well, although the client has mentioned what she needs at the beginning of the project, but in reality what she wants may change over the course of the project, and it’s not her fault! It’s just how the things are… No one can completely predict the project requirements and insist on that! Things may change and new decisions must be made.

• Weak estimations! As the tasks increase, the accuracy of how long each task takes decreases… Because unforeseen issues always arise, like bugs or client requirement changes and etc…

Now Scrum aims to fix these issues:

• It promotes transparency in a project.

• Inspecting and evaluating the project’s progress.

• Adapting to the project’s requirements along the way.

Scrum team major players

• Product owner: She is responsible for the overall project. She decides which features are important and prioritize the tasks that developers need to work on. She also may be a point of contact for stakeholders and tries to maximize the value of the project.

• Scrum developers: Write codes and test the software. They actually take care of the tasks that the product owner defines.

• Scrum master: Creates the communication bridge between the Product Owner and the developers team. He is usually possesses a strong technical knowledge, and actively participates in the development process. He works with the product owner to keep the Backlog ordered, and with the developer team to maximize productivity. He, however, does not micro-manage as the team is self-organized. He is responsible of organizing the sprint rituals, removing impediments and preventing unplanned works to be worked on.

How is the Scrum process?

Unlike the Waterfall process, We don’t work on the project from start to finish, instead divide the project into different pieces according to the product backlog and work on one piece in a short period of time known as sprint.

We would have a Planning Board for each sprint and developers aim to finish all of the user stories for that sprint on the board by estimating how long each story would take to be done before the sprint ends.

After each sprint we can also optionally measure our speed of development in that sprint by drawing a Burndown Chart to see how well we have performed and be able to improve our development velocity and estimations for the next sprint.

So in general, each sprint has a predetermined number of tasks and they happen in a short period of time. So in this way any barriers will be highlighted very quickly and be fixed, team members also remain focused on small number of tasks and know exactly what they need to do. Any unplanned tasks or requirements can easily be planned into the next sprint.
This whole process helps developers to have a constant speed of development, do better team work, provide early feedbacks to product owner and eventually build a better product.

NOTE: One important thing that we need to consider about Scrum is that a Scrum team is recommended to consist of between 4 and 9 members in total for a better performance and efficiency. So larger physical teams can split into several smaller Scrum teams.

What is Product Backlog?

It’s an ordered list of the tasks that should be worked on to deliver the product.
Product owner defines and maintains it. It’s actually a living list which grows, shrinks and changes as the projects is being developed.

What is Sprint?

It’s a basic unit of development in Scrum.
It should be more than a day long and less than one month. It’s commonly 1 or 2 weeks long. And the product should be in a stable state after each sprint.
So you may say how a project can get stable every week? That’s impossible! Well, in reality, it is possible and can be done, however, some rules are needed that we call them sprint rituals.

What is User Story?

A user story is a short, one sentence definition of a feature or functionality.
We call it user story because it is presented from the perspective of a user.
Actually the term user is the person using our application. This person can be a system administrator, manager, registered user and etc…

What is Planning Board?

It can be a white board which is placed on a wall(Can be a software too!) which has several columns.
The number of columns and their meanings differ from one project to another. In each column we would place colored sticky notes, which each one of them represent a User Story.
As the developer team is developing the software in the sprint, these sticky notes move from one column to another one and some new sticky notes may also appear to represent unplanned activities, bugs, etc…

How to estimate the amount of work that can be done in a single sprint?

Before starting a new sprint, we should decide which stories need to be done in the upcoming sprint. This may sound an easy job, but in reality, it’s a little bit complicated.

Product owner has some set of stories that developers need to work on. This list of stories typically contains more work than the team can achieve in a sprint, specially at first days of the project. Scrum master needs to convince the product owner, how much work can be done in a sprint, and over time the product owner learns the approximate velocity of the team and also the team’s productivity increases.

Now in order to understand our velocity, estimate how much time each story may take to be done and in overall how many stories can be done in a sprint, there are a couple of ways which help us in this process.

• Story Points: It’s one of the most common methods for estimating stories. A story point is actually the simplest story to be done and developers refer to it as the story of having one point. In some projects it can be only a ten minutes work, such as fixing an UI element; whereas, in some more complex projects it can be a two hours work which includes more than one person to complete.
  There are several point techniques to better help estimate stories:

  • Use Fibonacci Numbers: 1,2,3,5,8 (and maybe 13, but a 13-sized story seems too big).

  • Use Powers of 2: 1,2,4,8 (and maybe 16).

  NOTE: But please note that you should never associate story points with time! For example giving a 2 hour task, 2 points because it takes 2 hours, is wrong! Points should never relate to time. Why? Because as experienced teams have tested, this will make the estimation even worse.

• Semaphores: we can associate stories with colors instead of numbers to defines the complexity level of a story.
  So for example green defines easy tasks that can be done in the next sprint for sure, yellow is for a little complex story that may involve more than one person but still can be completed in the next sprint, red is for the story that is extremely difficult and cannot be finished in a single sprint.

• T-Shirt Sizes: We can use sizes like S, M, L, XL, XXL for our stories. This technique simply gives up on comparing story complexity with time of completion.

Estimation is a really important thing that we need to consider. Product owner and stakeholders need to know what to expect at the end of the sprint, they should be able to know when to release the product and what features are ready.

What is Burndown Chart?

It’s a chart that shows us our speed of development in a sprint.

So as an example imagine we have a 5 day sprint that 10 points need to be done within it. We Simply draw the chart for it and then show our actual speed of development(red) and the ideal speed(green) with two lines on the chart.
At the conclusion of each day, a team member volunteers to calculate the remaining points and draw the actual speed of development line(the red line) on the chart. And yes, finding the remaining points is an easy work if all of the developers move their own stories from column to column as they get finished on the board.

Our speed of development is ideal when the red line is close to the green line as we go on. The closer, the more ideal.

Don’t forget to be agile! In most of the projects after the first sprint, you may get disappointed when you take a look at your Burndown Chart! Because you couldn’t even finish half of the points that you liked them to be finished by the end of the sprint… Don’t panic! It’s ok.
So you can take less points for the next sprint to be able to finish them on time, for example 5 points in a 5 day sprint. And this time you may finish all the points too early! This is again not ideal, because what your team needs to do after they are done with all the planned stories in the sprint? Add new stories until they got time? Nope, they cannot redraw the original line again…
But there’s no worries, these things may happen but eventually after 3 or 4 sprints, you can easily make an average of the last charts, in order to specify how many points your team can finish for the next sprint.

NOTE: Remember that measuring velocity is not for judging the team, but it’s for making better estimations over time.

Let’s understand planning board better in an example

Imagine we have a board that consist of 4 main columns:

• Product Backlog: All the project stories reside here.

• Sprint Backlog: The stories that should be done in the current sprint are here and the team focus to finish them all by the end of the sprint.

• Working On: Team members take a story from the ‘Sprint Backlog’ column and put them here to show others what are they currently working on. This is needed for transparency and improving productivity.

• Done: This column is the place where all completed stories go. Ideally, all of the stories in ‘Sprint Backlog’ should be here by the end of the sprint.

As each sprint starts, some stories will be moved to ‘Sprint Backlog’ from the ‘Product Backlog’ and all of those in the ‘Sprint Backlog’ should be moved to the ‘Done’ column.

‘Working On’ Column:

And yes, the ‘Working On’ column itself can be separated into more columns according to the project. For example we it can be divided into 3 columns: Design, Development and Testing.

The Definition of Done:

The definition of Done is very important. We should clearly state that what do we mean by Done, and when a story is considered as Done and can be moved to the ‘Done’ column on our board.
Actually there is no exact rule for this, but we need to define for our project according to our needs and tasks.

We can for example consider a story as Done when all of the following steps are done with it: Analyze data, draw sketch, create GUI mockup, write unit tests, write code, refactor, make sure tests pass, let another team member test manually, pass functional or acceptance tests, compile and publish.

As I said, these steps may be vary from project to project, but you need to define them for your project. And remember to adapt yourself too over time! If you notice that your definition is becoming outdated, consider removing some elements or adding necessary.

Feel free to organize the sticky notes and stories on the board:

A User Story may be a complex task to achieve so feel free to divide it into smaller tasks and use different colored sticky notes to represent them on the board! In our example we have used yellow sticky notes for stories and light blue for tasks.

Bugs may appear at the middle of the work and it’s very important to resolve them and track them down, so use another colored sticky notes, like red to represent them on board.

In each step of the process, some tasks that they themselves are part of a bigger story may be considered as Done, use green sticky notes to represent them.

Certain activities must be completed in order to finish a task, story, or the sprint as a whole. These activities may not be part of a story but must be done. Like installing a third party application to implement a functionality. This activity may not be an actual task that is related directly to our project development but it is needed, so we should be able to separate it for easier management. We call such works Technical Tasks or Activities and show them in light green color sticky notes.

For transparency to see which team member is working on a particular story, you can write that person’s name on the sticky notes or like what we did in our example, stick a small bookmark on each sticky note which contains the team member’s name.

These are just some ideas to organize your board and sticky notes according to your own project and team. Of course you can invent your own rules, no worries. Manage your board in any way that you feel more comfortable with.

Introducing sprint rituals

So as we know, after each sprint, our product should be in a stable state. But how is that possible? Well, we need some rules and meetings which are called sprint rituals.

Sprint planning

Occurs at the start of the sprint. Teams review the product backlog, pick up some of the high priority tasks and try to deliver them by the end of the sprint.

How long does it take? This meeting can take a whole day, but shorter sprints only need a couple of hours or so.

What are its results? After the meeting we will have sprint backlog. It includes some tasks that need to be done in the current sprint from the product backlog.

Stand up (Daily Scrum):

Occurs early in the day at an exact hour and each team member needs to answer to the following three questions:

1. What you achieved yesterday?
2. What you will achieve today?
3. Are there any problems blocking you?

Scrum master should help to solve the blocking problems and impediments. Sometimes the problems can be solved in a timely manner but other times, there might be a serious issue that solving it itself would take a couple of weeks. Resolving any blocking issue that is preventing the development process should be the team’s high priority.

How long does it take? Stand up should be fairly quick, each team member should only speak for a couple of minutes. That’s why all team members stand up and speak, so after a little while if you have seen that someone is looking for a chair to sit, it’s probable that the meeting has gone too far!

What are its results? Transparency about what each team member is working on and identifying the impediments.

Sprint review:

Occurs at the end of the sprint. Developers, scrum master and product owner discuss what has been achieved during the sprint. And a Demo should be prepared to show to the product owner the new features that has been added.

How long does it take? Well not more than an hour or so. It depends on the number of features and how you like to showcase your demo.

What are its results? Based on the demo, product owner can decide whether to publish a new version of the application or not. Sometimes although the added feature is not completed yet, a release will help to gain users’ feedbacks early in order to decide what to modify to satisfy more users as much as possible.

Sprint retrospective:

Occurs at the end of the sprint. In this meeting developers provide feedback about what went well in the passed sprint and what went badly. There are no right or wrong answers here, developers simply give their own opinions. They should put aside their own personal feelings and speak about what is bothering them.

How long does it take? It’s a short meeting that wouldn’t take more than an hour if there were no serious issues that is bothering team members.

What are its results? The most important thing is to propose a solution for any problem and let everyone a couple of minutes to think about it so that we can avoid it for the next sprint.

What’s next?

In this tutorial I tried to cover anything important about the Agile Development Process and Scrum. Explained the Scrum benefits, major players, how to estimate and some of its useful techniques, sprint rituals, Burndown Chart, Planning Board and some other terms such as Product Backlog, Sprint and User Story.

Like to learn more? Checkout the following resources:

• “SCRUM: The Story of an Agile Team” is a great tutorial by Patkos Csaba that teaches Scrum from a practical point of view and his own experiences as a team member in an agile team.

• scrum.org is where you can get Scrum certifications and take courses.

• scrumguides.org is where you can download the official Scrum PDF Guides and learn more about its history and philosophy.

Reproduced under an MIT licence.