Skip to main content

The Agile Manifesto

In February 2001, 17 individuals came together and wrote the Agile Manifesto, which says:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

  • Individuals and interactions over Processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

© 2001, the Agile Manifesto authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

 

The Agile Manifesto in detail

But what does all of the above mean when it comes to carrying out Agile methodologies in practice? Let’s look at each point in turn – as our team use Scrum, that’s the framework that I will use for reference.

 

Individuals and Interactions over processes and tools

In Scrum, the team is all. They must work together to plan Sprints, estimate, do the work – the list goes on. There should be effective interaction both within the team and with individuals outside it so that the Scrum team can establish a good quality Sprint Goal and work towards it.
Regardless of who the interactions are between, the most important aspect is to ensure free flowing communication. This can be achieved by:

  • Creating a blame free culture
  • Ensuring individuals are able to speak up (see planning poker and silent writing)

 

Working software over comprehensive documentation

The aim of each Sprint is to produce a working increment of potentially shippable product. Agile values an increment of working software over large amounts of documentation which likely provide no business value.

documentation
Comprehensively planning and documenting user requirements don’t give you anything of business value. It’s only when an increment is developed, that we get a return on investment.

However, we still need to create documentation as long as it doesn’t interfere with the development of the increment. I would also say that user guides, for example, can create business value – without it, users may be unwilling to use your product.

 

Customer collaboration over contract negotiation

Only by collaborating with your customer can you understand what they want. You might think you know what they want, and you can even suggest this to them. But ultimately, you need to build a product that has the features they require.

This is even more important in Agile, where we focus on adding features that will add business value. The Product Owner (acting as a proxy for the customer) doesn’t want extraneous features adding, just because the development team thought it’d be cool. I’ve seen examples of this and it’s a perfect way to really annoy your customer.

collaboration

I would say that once you start to have an idea of requirements, this can be put into a contract. But the contract needs to allow for changing requirements. If we were doing Waterfall, the contract would be set in stone, alongside the requirements, at the start of the project.
But we’re doing Agile, we expect the requirements to change, so that contract needs to account for this.

The beauty of Agile is that the requirements will naturally emerge as the project progresses. The customer sees the increment during the Sprint Review and this allows them to feed back on what they like and what isn’t as they expected. This feedback is then used to adapt the increment in the next Sprint.

Underpinning all this is communication. If the developers aren’t sure what the customer wants, then ask the customer.  If you ask them straight away, you can prevent minor issues from growing into large problems.

 

Responding to change over following a plan

In the Waterfall model, we create detailed plans right at the start of the project. But this is the time when we’re least equipped to plan – we don’t know enough about what’s required from the product. Once you realise that change is required, it’s often too late.

plan

Agile accepts that requirements will change and emerge as the project progresses. We do plan in Scrum, but it’s a continuous process. By utilising relatively short timescales (the Sprint) we are offered more frequent opportunities to inspect the product and adapt it.

If a plan isn’t working, then why stick to it? Look at why it isn’t working (inspect) and change it (adapt) based on past experience.

We also ensure that we don’t plan too far ahead. If we plan too far in advance, by the time comes to implement the plan, the product and environment are likely to have changed, rendering the plan useless.

 

Conclusion

When working on a Scrum project, it’s important to try and keep the Agile Manifesto at the back of your mind. Think to yourself:

  • Are my interactions with others adding value or are they causing impediments?
  • Do we need this amount of documentation or can we take advantage of “Simplicity – the art of maximising the amount of work not done”
  • Are we effectively collaborating with the customer?
  • Is our plan working, and if not, why not? Are we able to inspect and adapt it? Are we planning too far ahead?

 

Read the original Agile Manifesto, and get translations, here.

Product Backlog Prioritisation Techniques

Two of the Scrum Masters’ responsibilities to the Product Owner are:

  • Finding techniques for effective Product Backlog management;
  • Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

So let’s look at a few practical techniques for prioritising/ordering the Product Backlog.

I have focussed on qualitative methods here as I find they are the easiest for Product Owners and stakeholders to quickly pick up. Of course each person will have their own agenda when it comes to their ‘must have’ features and these features are always the most important to that individual. But people will always have a bias – I have even heard of quantative results being overruled because they did not fit with what the managers at the organisation wanted – so perhaps it is better to accept this fact, rather than pretending you’re prioritising objectively.

 

MoSCoW

Using this method, Product Backlog Items are categorised into one of the following:

Must have – these must be included in a product for it to be regarded as a success.
Should have – high priority items that should be included wherever possible.
Could have – lower priority items. These are generally ‘nice to have’.
Won’t have – items that won’t be implemented at the current time. However they can be reconsidered in the future.

Within each category it may be useful to further order the items.

 

Buy A Feature

Using the concept of gamification, this method can make prioritisation more fun, while still discovering what the stakeholders want. Simply follow these steps:

  1. Provide a cost for each item that needs prioritising. This may be based on developer effort, complexity or actual cost to develop.
  2. Get the stakeholders together – this works best if they meet in person.
  3. Present to them the items that need prioritising.
  4. Each stakeholder has an allowance of money e.g. £100
  5. Stakeholders assign their money appropriately to the features that they want. They can buy individually or club together with others in order to buy more expensive items.
  6. Items can be bought more than once, by different stakeholders.
  7. The items can then be ordered by the amount that has been spent on them – whether this is low cost items that have been bought many times, or more expensive items that people have collaborated to buy.

 

Priority Poker

This works in the same way as Planning Poker. First, decide on a ranking scale for items – the Fibonachi sequence is popular (1,2,3,5,8, etc).

In a group, every person has card for each of the ratings.

The item to be ranked is read out to the group and each member selects a card based on their perceived priority. They must keep their card hidden until everyone has chosen.

Once every member of the group has selected a card, they are all revealed simultaneously.

If the selected priorities are all similar, then the group is in agreement. If there are outliers, then the differences must be discussed in the hope of aligning everyone’s views on the required priority.

The same item is then ranked again by repeating the steps above in the hope of achieving consensus. If consensus still can’t be reached it may be that the item needs refining into smaller items or that an average (median) score is used.

Alternatively the group may need to decide not on the ‘perfect’ priority, but one they can support.

 

Kano Model

The Kano model challenges the idea that improving every aspect of your product results in an increase of customer satisfaction. In reality, there are areas of basic expectation in a product that a customer would always expect to be there – often these can require a large amount of effort to develop. Conversely, there maybe features that would impress users but require very little effort to create.

Mandatory features – must be present in order for users not to be disatisfied

Linear features – the more of these there are, the more satisfied a user is

Delighters – Features that are high up the satisfaction scale.

The Kano model is a little more in depth than the other methods of priorisiation that I’ve mentioned, so I’ll put it into it’s own post. That way we can look at its theory in detail and see how we can use it practically when prioristing the Product Backlog – Using the Kano Model to prioritise the Product Backlog.

Kano Model – Product Backlog Prioritisation

The Kano model challenges the idea that improving every aspect of your product results in an increase of customer satisfaction. In reality, there are areas of basic expectation in a product that a customer would always expect to be there – often these can require a large amount of effort to develop. Conversely, there may be features that would impress users but require very little effort to create.

Categories of features

Basic features – must be present in order for users not to be dissatisfied.

Indifferent features – Features that don’t affect a customers’ satisfaction one way or the other.

Linear features – the more of these there are, the more satisfied a user is.

Delighters – Features that are high up the satisfaction scale.

 

We can’t create only features that are high in satisfaction. This is because of the Functionality dimension, which represents how well a feature has been implemented, how much has been completed or how much it cost to develop.

Kano chart

The Four categories of Features

Basic/Mandatory features
Features that users expect to exist in a product are unlikely to score highly on satisfaction, but developing them can be costly. But if a basic feature doesn’t exist, users are likely to complain.

For example, a basic feature for a hotel would be ensuring 24 hour hot water. They require large expensive boilers (with associated fuel usage) that can supply instant hot water. The hotel must spend huge amounts on ensuring the hot water is available, but users will never get excited by it because it’s something they expect.

 

Indifferent features
Features that don’t really affect the satisfaction level of users. So no matter how much effort is put into developing them, it won’t make any difference to the happiness of your users. Because of this, think carefully about if you should be developing these features.

 

Linear features
The more you provide, the more satisfied users become. For example, battery life of a mobile device.

 

Delightful features
These are features that score highly on satisfaction, but may only take a small effort to create. If they aren’t present, a user is unlikely to complain. But if they are present, they will be delighted by the product.

Going back to the hotel example, providing guests with a free drink probably only costs a few pence, but is likely to score highly on satisfaction.

 

Delight changes to Basic

Over time, features that were originally classed as Delighters, will change to Basic features. For example, once users start to expect a free drink on arrival at their hotel, they will become dissatisfied if they were to no longer get the drink – it has become a basic feature.

 

Using the Kano Model to prioritise the Product Backlog

To discover how users see our products’ features, we conduct a Kano questionnaire. For each feature, we ask two questions:

  • Functional – How do you feel if this feature is present?
  • Dysfunctional – How do you feel is this feature is absent?

For each question, the user may answer with one of the following:

  • I like it
  • I expect it
  • I am neutral
  • I can tolerate it
  • I dislike it

Their answers can then be categorised using the following grid:

kano grid

Mandatory
L
inear
E
xciter
Q
uestionable
R
everse
I
ndifferent

So if a user answers the functional question with “Like” and the dysfunctional with “Neutral”, the feature will be classed as E, or Exciter.

You’ll notice we also have two new categories:

Questionable – these occur when the user gives conflicting answers e.g. like for both answers. This suggests there’s something wrong with what you’re asking.

Reverse – this suggests the user actually wants the opposite of what we’re suggesting for the feature.

 

Once your users have completed the questionnaire, you can aggregate the results. For each feature, add up the responses in each Kano category. The category for a particular feature is the one with the largest amount:

kano results

So we can see that login using Facebook is a Mandatory feature, upload a photo is Linear, and share photo with friends is an Exciter.

When it comes to prioritising the Product Backlog, you need to include the Mandatory items as your highest priority, followed by Linear and then Exciter.