Agile and relevant practices

The agile environment I’m going to use is based upon the two methodologies eXtreme Programming (XP) and Scrum. XP focus’ a lot on programming and delivering high quality code and Scrum is a management framework for managing projects. I will be writing about a couple of agile practices: iterative development, product owner, user story, sprint backlog, business value and test-driven development.

Iterative development

Iterative development is where you work in iterations, though in an agile environment it’s called sprints. Sprints are time boxed, which means each sprint is fixed at a certain amount of time. Sprints can for example be set to two weeks. So in two weeks you have to finish the user stories on your sprint backlog.


Backlog is where the product owner puts all user stories that is involved in the project. When a new sprint starts, the product owner assigns user stories from the backlog to the sprint backlog, so the developers knows what to work on in this sprint.

Product owner

Product owner is a scrum practice, where you assign a person to be responsible for a project’s success. The product owner is the voice of the customer and stakeholders, she is the one that conveys their opinions and thoughts on how the product is supposed to work, this is provided in the user stories.

User story

A user story contains a short story on how a certain feature is supposed to work in the project. An example of a user story using Gherkin could be as follows:

Business value = 3000
Complexity = 48 hours
Feature: Register user

In order to use the system
As a new user
I need to be registered.


Given I am on the “New user” screen

Scenario: I want to register as a new user

When I insert “Harry Potter” in the “Full name” field
And I insert “” in the “E-mail” field
When I click on the “Register new user” button
Then I should see “User registered”

Scenario: I try to register as a new user with a wrong e-mail

When I insert “Harry Potter” in the “Full name” field
And I insert “” in the “E-mail” field
When I click on the “Register new user” button
Then I should see “That’s not a valid e-mail”


The language and setup used in the user story is called Gherkin. Gherkin is a small language is “business readable”, so that everyone can understand it.It let’s you describe behaviour and usually without detailing how that behaviour is implemented. But if the product owner want a certain GUI the user story can be more detailed like the one above. Gherkin can also be implemented in several other languages, like french or danish. By implementing them in other languages, your product owner can write in her native language instead of having to translate all the demands into English. The words encased in quotation marks, are replaceable words, these words are usually checked by regular expressions, but I’ll cover that in ‘Scenario and steps’.

Business value

Business value is assigned to every user story, it’s an integer that shows how important a feature is to the stakeholders and users. Business values vary a lot, but I will use the following values: 100, 200, 300, 500, 800, 1200, 2000, 3000, where 3000 is extremely crucial. The Register user feature from before is assigned with 3000 since you can only use the system if you’re registered, and that’s obviously, extremely crucial.


Since a sprint is time boxed, and in this case two weeks, the product owner needs to assign two weeks worth of user stories. That is why the developers estimate complexity to the user stories in the form of hours. So let’s say we have have a team of three developers that work 37 hours a week with a two week sprint that is 222 developer hours. So the product owner needs to assign user stories with a total complexity of under 222 developer hours.


The user story is rather easy to read, the product owner wants a feature and she describes different scenarios in how it should be used. The text under the feature follows the feature injection template made by Chris Matts and Liz Keogh:

In order to <meet some goal>
As a <type of stakeholder>
I want <a feature>

This template makes it clear, what feature you want in the system and it can easily be changed if someone comes up with an easier solution.


Background is used to set up the background for the test, like “Given I am on the “New user” screen”. Background also saves space in your test, because the Given statement is true for all tests and so, without background we had to write it in every line.

Scenarios and steps

Each line in a scenario is called a step. Each step start with Given, When, Then, And or But. These steps describe how the user will interact with the system and how the system should respond. Scenarios also follow an abstract template(from The Cucumber Book):

  1. Get the system into a particular state.
  2. Poke it (or tickle it, or …).
  3. Examine the new state.

This template pretty much sums up what all scenarios do.

Given describes a certain state in the system, like: “Given I am on the “new user” screen”. When describes what a user does like: “When I click on the “Register new user” button”. Then describes how the system responds like: “Then I should see “That’s not a valid e-mail””. And and But are so we can add more steps to a Given, When or Then.

Scenario outline

Scenario outline is yet another time saver, you save time by running multiple tests in a single scenario instead of having to copy paste. The scenario outline is a template that is never directly run.

Scenario outline: I want to register as a new user

When I insert <name> in the “Full name” field
And I insert <e-mail> in the “E-mail” field
When I click on the “Register new user” button
Then I should see “User registered”


| name     | e-mail                       |
|Daniel    |    |
|Rasmus   ||
|Lara       |      |
|Emma    |    |

It is never directly run since the data provided in Examples replaces the tags: <name> and <e-mail>. So in this example the scenario outline is run four times since the first line with |name| and |e-mail| is never run.

Living documentation

Living documentation is documentation that is continually edited and updated.

All the tests you write in BDD are living documentation. If you check out a class’ adhering test you can see what the class does, because it is described in the test. Unlike normal documentation, where sometimes the only one who understands the documentation is the person who wrote it. Also in BDD you have to keep your tests up-to-date/alive and so, your documentation along with your tests, are never behind. This documentation doesn’t just cover class-wise, but also how the classes should behave together and should look like in the GUI. Again, one of the main things are that the business people can see what features have been implemented by running the tests.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s