I recently came across an interesting situation while developing a module for an existing website. The project required us to take an existing satellite website, make it responsive and incorporate it into the organizations main website; and, this is the interesting bit, make it work ‘as is’.

The requirements for the module were fairly simple; it had a search facility that allowed users to search for properties throughout England, comprising a quick search, an advanced search and a map search. Search results would then allow users to click through to a property information page.



Before work started I didn’t think too much about the ‘as is’ part and assumed that the website had been tested with end users throughout the original development process; I’d clearly been wearing my agile blinkers. As it turned out, although there were over 80,000 hits to the site each month there had never been any external feedback gathered from end users. The only feedback that had been discussed was from internal stakeholders. What’s worse is there were no personas created so we didn’t even know who the uses were.

The issue was that the requirements were being driven by the stakeholders who wanted to take all the existing features, make them responsive and add any other improvements along the way. There was a very real sense that the product would not be as good if stakeholders lost some of that existing functionality; it felt that the existing product was a type of requirements specification. None of this was feeling very agile, agile is about doing enough to get user feedback, delivering incremental value, letting requirements emerge over time, embracing change and looking for opportunities.

I decided to undertake some research and I soon came across articles that suggested that where software had been developed using a traditional waterfall method, end users only used about 40% of the functionality with 60% never or rarely being touched (Forrester Research). The other interesting statistic I discovered was when users where asked to list all the features they thought a software application should contain, about 30% of the items they listed were missing.


Do we really need all these functions?

We were about to start sprint 0, the product vision had been written, so I suggested to the team they review Google Analytics and gain insight into how often features were used, the results were very interesting; despite all the sophisticated searching functionality and complex features 54% of users used Google search and were arriving directly at the property information pages! Furthermore for the users that did use the advanced search, less than 1% of users used many of the filters. Could this 1% possibly be the stakeholders we asked ourselves?

This proved incredibly useful as it helped the product owner prioritise what the team worked and going into sprint 1 the team focused on redesigning a responsive version of the property page as their highest prioritised item.

There are still a few battles in terms of the stakeholders and what they want as there are a few features they use themselves and want to keep even though they are not used by the vast majority of users. However we have managed to put these to the bottom of our prioritised product backlog so if they don’t get done then we won’t be too upset.

This was a useful exercise to test the agile process and how we work with existing software. It made me think about how we communicate to both product owners and stakeholders how to get the best possible product developed in the time we have available, even if there is an existing product. I produced the diagram you see above based on the information I’d read at Forrester. There is an assumption by me that if users only use 40% of features in software then this equates to 70% of the items they would expect to use in the software. Product owners and business analysts still need to identify the missing 30% of features. Stakeholders should aim to get the best possible product for their budget, focusing on users and the features they require will ultimately lead to the development of the best possible product.




  1. Comment by sikis izle

    sikis izle Reply May 2, 2016 at 7:37 am

    Hola y gracias por este blog es una verdadera inspiración ..

  2. Comment by sikis izle

    sikis izle Reply May 7, 2016 at 6:22 pm

    excellent article.

  3. Comment by sikis izle

    sikis izle Reply May 8, 2016 at 5:28 am

    Bonjour, ton blog est très réussi ! Je te dis bravo ! C’est du beau boulot !:)

  4. Comment by zayiflama

    zayiflama Reply May 12, 2016 at 1:23 pm

    Merci pour le partage.

  5. Comment by FreeBSD VPS

    FreeBSD VPS Reply May 13, 2016 at 9:43 pm

    For example, while waterfall is driven from the top down, agile encourages every member of the team to expose what they learned in a sprint, allowing other team members to apply the new shared knowledge in future sprints. Team members may find it frustrating if they are encouraged to behave as if they were in one type of organization, while simultaneously being expected to conform to the structure of a different type.

Leave a reply

Your email address will not be published. Required fields are marked *

Go top