Documenting your product aids the iterative process

When developing a product iteratively against a prioritised backlog, it’s common for developers to want to move on to the next user story as soon as possible.

Having spent considerable time restoring my home, I know that it’s so easy to complete 99% of a job. Before you realise it you’ve got a number of jobs outstanding that just need the 1% to be finished before you are satisfied.

When working on a particular feature for a while it’s easy to get feature fatigue and the desire to start on something new sets in.

But, as the following agile principles outline, we need to be willing to make necessary changes that support our customer needs as well as providing a well-designed technical solution.

2 of the 12 principles of Agile

1. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
2. Continuous attention to technical excellence and good design enhances agility.

Feedback loops

How you identify those changing requirements and maintain continuous attention to detail will vary depending on the type of project that you are working on.

User testing

I’m my last post I mentioned we’ve been using a product called [Lookback] (https://lookback.io) to record the outcomes of our user testing. For us user testing provides the quickest way to identify issues that our users are likely to face with a new feature or improvement we’ve made.

User testing isn’t the magic bullet though, as it’s usually focused on a particular use case, often tested outside of a person’s normal environment, and is often based on specific test cases.

Sprint reviews

Sprint reviews are one of the methods we use to identify these changes. They provide a focused opportunity to gain feedback on or discuss a particular feature that the team have developed in the previous sprint.

Great ideas come out of these discussions, and they should be raised as potential backlog items to be addressed by the product owner. But some voices are louder than others, and it’s easy to miss out on subtle changes that will improve the experience for large proportion of users.

This has definitely been highlighted as we’ve been writing our documentation for Contensis 9.

Documentation as a silent feedback loop

Over the last few weeks we’ve been documenting the features of Contensis 9. This has provided us with some really rich feedback on the product and how authors and developers will interact with the UI and API.

It’s amazing how many little things you come across when you spend time using and documenting the product that you’ve been building.

We’ve been able to surface a number of bugs to be fixed, behaviour inconsistencies to be corrected, and improvements to be made. These changes will help fulfil those agile requirements I outlined at the beginning of this post.

Aiding the development process

By taking stock of how far you’ve come and spending time on documenting what you’ve done, before you move on at warp speed to deliver new features or behaviour, can help highlight the 1% of changes that may have some of the greatest impact on your product.

So as you build products – whether they are websites or applications – consider the feedback loops outside of those that are audible and obvious.