Agile Product Development

In today’s post we take a deeper look at a statement from the essay we have already been covering in a series of Hungarian blogposts. The passage we would like to analyse states: “Product development and architecture aren’t the programmer’s job, because they take longer than two weeks. Rather, the programmer works on atomized feature-level ‘user stories’.

First, let’s examine the definition of Product Development (complex architectures will be covered in a separate post). According to Product Development is “The creation of products with new or different characteristics that offer new or additional benefits to the customer. Product development may involve modification of an existing product or its presentation, or formulation of an entirely new product that satisfies a newly defined customer want or market niche.”

Sadly, this definition, just like the agile manifesto, lacks differentiation between customers and end-users. They might be the same, but this is not always the case: often the person purchasing the product differs from the one who will be using it. Ideally, the product has been developed for the needs of the end-user, but sometimes a feature is only needed to sell the product, not for real usage. This is not necessarily a problem, but we need to know the purpose of the feature in order to put the appropriate amount of effort into its development.

Let’s just put this laxity aside for simplicity’s sake and take a closer look at product development.

Team members work on user stories, but what’s a user story, anyway? It is a way to phrase user requirements – often purposefully short on details – which helps all participants to step into the end-user’s shoes thus enforcing communication between business and development sides in order to mutually understand requirements and to find the best possible solution. Instead of stating how the system should work, Business communicates problems to be solved to development.

Another huge advantage of the user story format is vertical task definition: one story comprises tasks needed to be performed in each layer of the system to fulfill the  requirement. This is not the case with a horizontal approach, where a task can be for example to design a new database table without even knowing the real user requirements and the intended usage of the data to be stored there.

Requirements are formulated and broken down in a way that members of the development team build the system looking through the eyes of the end-user. If a requirement does not provide value for the user, it is extremely hard to formulate into a proper user story. As an example, take a look at this sentence:

“I, as a reader of the online news portal, would like pop-up ads on the site in order for the publisher to make revenue.”

This is simply not true, because the idea does not originate from the actor in the story.

As the user story format brings the end-user of the product very close to the developer- the complete development team, testers included – we can state that they have never been more in charge of product development than these days.

For example, if the original story requests a separate view, listing customers with due payments, developers can argue for a cheaper alternative: a new, filterable column on the current customer view can provide the same goal for much less work and it also keeps the codebase simple and clean.