Agile Methodology – definition

Here is an article to understand the agile methodology. What could be better than an example to understand? Indeed, if you discover agility, it is not easy at first to understand what an agile scrum method is.

Take a topic like an example

To start, I want to create a new blog dedicated to the agile methodology scrum called scrum.sg.

Here is what this blog will present:

• all the elements defined by the scrum framework
• will only present elements from the guide scrum
• will offer clear illustrations

The subject is simple but will allow us to properly lay the foundations of our example.

How do we start our agile methodology?

Indeed, it is not easy to start a project with the agile methodology scrum without any preparation.

Start with a preparation phase

For my part, I recommend to prepare a first vision of the backlog; for that, don’t hesitate to go and see agile framing which is a 100% agile product launch framework.

It will:

• align the team around the mission and objectives
• to have a vision of the product we want to make
• view the risks and the product roadmap
• define the organization and governance of the team

Website: Agile Framing

At the end of your agile framing, you will have defined a first backlog with some elements “ready” to be developed and many elements not yet detailed.

The team will have taken the time during the agile framing to define the definition of done which determines all the criteria which will validate that an item is finished is potentially publishable in production.

Article: definition of done (agile methodology)

Start your first sprint

As a reminder, a sprint begins with a sprint planning and ends with a sprint review and a retrospective. The scrum master will help the team to become independent throughout the sprints.

Here is a simple little diagram of the agile methodology scrum:

Agile methodology: sprint planning

During this sprint planning, the scrum team will define its backlog sprint with the following elements:

• the sprint goal
• items meeting the sprint goal
• the implementation plan for these items (technical subtasks, scheduling, etc.)

Here is what the scrum team defines together for our example blog:

sprint goal: “display a first version of the blog scrum.sg”

items selected by the team:

• As a visitor, I want to see the home page with the latest blog posts
• AS a visitor, I wish to be able to obtain the RSS feed for articles
• (and) As a visitor, I want to be able to read a full article

To meet the requirements of the scrum guide, the product owner had completed the items with:

• gherkin tests to explain how to test them
• the value of each of them
• the dev team’s estimate of each previously.

The development team and the product owner then agree on the “how” to meet these needs during this sprint planning. This is the famous “plan” expected during the sprint planning. And indeed, this part is often underestimated.

The team must talk about the solution

Solution proposed by the development team: put a wordpress that meets the 3 needs with the installation of wordpress and some configurations.

The product owner decides to validate the solution. The development team will then purpose to the product owner to add items because they are convinced that they can do more.

Moreover, they also indicate to the product owner, that certain items will also have been made thanks to this solution:

• As an author I wish have the capacity to write an article on the blog
• As an author, I would like that my administration part of the blog is secured by a login / password access

So as you can see, depending on the proposed and / or validated “plan”, this can change the entire sprint backlog. Sprint planning is not just the choice of the items to do but the moment to talk about how the development team will do them. And that is the real difference between the agile methodology scrum and the traditional methods: organize properly the work with small iterations.

And I took this example because it shows that the “plan” can change the whole physiognomy of a sprint imagined upstream.

The team must divide into technical subtasks

As the user stories are not technical, the development team will split each of the user stories into technical subtasks.

As a visitor, I want to see the home page with the latest blog articles

The development team will define the technical splitting adapted to the chosen solution, knowing that this first user-story will be treated with by the team:

• install a development environment
• set up a recipe environment
• install wordpress
• configure wordpress for “scrum.sg”
• configure the home page to display the latest articles
• make fake articles to properly check the display

The development team will also define the order of development of the user-stories (at least for the first ones).

Agile methodology: realization begins

At the end of the sprint planning, the development team will start the realization phase.

At each time that the development of an element will be done, a member of the development team will check that it respect all the criteria of the definition of done before to put it in “done”.

As a reminder, it’s not the product owner who does this, but the development team.

Agile methodology: daily scrum

Each morning the team will do a classic daily scrum. Each member of the development team will say:

• what he has  done since the last Daily
• then what he plans to do until the next Daily
• will possibly raise an alert

Agile methodology: sprint review

The product owner invites the development team and stakeholders to review the sprint.

He will remind the sprint objective: “display a first version of the blog scrum.sg”.

Then the development team will explain all the items they finalized and the unfinished ones of the backlog sprint. She will take the opportunity to explain the obstacles encountered if there are any; and they have to indicate whether the sprint goal has been achieved.

When everything is done, the team will present the first version of the blog (objective achieved) in order to obtain feedback from all of the participants in this sprint review. With this feedback, the product owner will add new items that are not detailed in the product backlog.

All the participants will define together how to advance on the product in the next sprint.

Agile methodology: retrospective sprint

The scrum team will isolate themselves at the end of the sprint to do a sprint retrospective in order to look for axis of improvement to implement during the next sprint.

Our team will define the following axis of improvement:

• improve our visual management
• analyze wordpress plugin to avoid to redo some work
• analyze wordpress security

Conclusion agile methodology

To conclude, I hope this example about a sprint will help you to better understand how scrum takes place. Besides, don’t hesitate to go and see our basic scrum training: scrum – our guide