Blogi 16.8.2017

Time to Choose Your Metric – Part Two

Kiva kun löysit tämän artikkelin! Se sisältää varmasti hyvää tietoa, mutta pidäthän mielessä, että se on kirjoitettu 7 vuotta sitten.


My previous blog post focused on making the meaning of metrics, why should you avoid having too many metrics, and which metrics are used in software development. I concluded that ‘time to feedback’ is the best metric to manage a software development process. This blog post gets deeper into the time to feedback metric’s anatomy.

The Noble Metric

The time to feedback defines the time elapsed between the identification of a requirement and customer feedback. The final goal is to gather the customer feedback at the earliest chance. The benefit of the time to feedback metric is that it measures the whole process, not only one part. This avoids sub-optimizations and leads software developers, system specialists, UX designers, product owners, and other development people to co-operate.
Here are few practical actions that help to reduce the time to feedback:

  • Work continuously with your customer
  • Do as few things as possible at the same time
  • Focus on prototypes and ‘Proof of Concepts’
  • Minimise your task size
  • Keep your backlog as short as possible
  • Release as quickly as possible

Above actions are also considered the best practices in software development. This shows the metric is selected wisely. Now it is time to implement the metric.

In God We Trust, Others Bring a War Room

During the second world war, English prime minister Winston Churchill needed a place where he could ‘direct the war’. Churchill and his team built war rooms under London where the core team met daily and the crucial information was available. The war room’s walls were covered with important statistics, maps, and reports, and they were updated daily.
A project room should be set up using the same principles. The room is simultaneously a workplace, meeting point, and knowledge centre. Whiteboards or printed excel sheets are an easy way to hang the metric data. Be sure that your data is visible, clear, updated, and explained to everybody—also to the executive team.

A Simple Graph is Enough

Collecting the time to feedback data is fairly simple. Write down the creation date of the task and when the feedback is gathered. Create a graph and update the average time to feedback monthly. If the data is not collected in every task, make sure the sample data is large enough.
There are numerous ways to gather customer feedback. Surveys, comments, tests, interviews, and on-site activities are just a few examples. The collaboration with your customers must be on daily basis, and not a complicated process.
Unless you are working with remote or distributed teams, there is no need for fancy issue-tracking systems, such as Atlassian Jira. These systems are expensive, highly complicated, and need a dedicated person for maintenance. Issue-tracking systems come with a wide range of reports, however, the proper ones are usually missing. If you work in conditions of remote or distributed teams, using the simplest track-system such as Trello and sharing your data via a wiki or collaboration tool is the ideal recommendation.

The Next Challenge

Adding a couple of more metrics to your software development process is possible, but keep in mind that too many metrics give mixed signals and are time-consuming to maintain. When the software development metrics are up and running, it’s time to concentrate on the more important question: how will the customer feedback change your product?

Graphic design

Ville Takala

References

http://www.historyextra.com/article/bbc-history-magazine/secrets-churchill-war-rooms-history
https://www.blossom.co/blog/remote-versus-distributed-teams
https://www.helpscout.net/blog/customer-feedback/
 

Takaisin ylös