2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- April 3, 2019
- Build in Small Batches
I always say that doing the right thing is far more important than doing the thing right, if we only have to choose one of them. Of course, we don’t we can choose to do both and that’s when software development is at its best.
It doesn’t matter how elegant our code is or how beautifully designed a feature is if the customer can’t use that feature or if it doesn’t address their needs. We got to give the customer what they need and deliver it so that it’s stable an extensible as well as independently testable.
But how do we know that we’re hitting the mark with our customers for the features that we’re building? How do we know that our customers are gaining maximum value from the features that we build for them? The answer is, of course, that we measure it.
Measuring the value of features to customers involves both subjective and objective indicators. How customers feel about features is just as important as how productive they are when using those features. If customers don’t feel productive with the features then they won’t use them.
If you want to know if a user likes a feature then just ask them. Users are often quite anxious to let us know what they think of the software that they use, especially if there’s room for improvement. Surveys are a great way to measure what our customers think of the software we give them. Also, because our software interacts with the user, we can see with relatively little effort how our programs are being used by building telemetry into our software. We can do this anonymously so we’re not violating any privacy agreements and seeing how our software is being used can oftentimes give us great insight for improving usability and that can make our customers even happier.
This could be as simple as tracking the number of times that a feature is invoked through a menu and then comparing the results at the end of quarter or the end of the year, which features got the most usage and which features got the least usage. There are many opportunities to get feedback from our customers on the value of what we deliver and that feedback is of paramount importance for us to create new features that continue to address the needs of our users.
Understanding what our customers want can often be challenging for many software companies. We assume that they want the things that we want but very often customers of a product see the product very differently than the creators of the product and so staying in touch with what the customer sees and experiences is a very healthy thing for the team in order for us to continue to address the needs of our users.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Measuring Software Development.
Previous Post: « Measure Time to Detect Defects
Next Post: Measure Costs of Not Delivering Features »