Category Archives: agile

Flexible and agile management of requirements

On April 11, 2013 Dr. Andreas Birk and Gerald Heller provided a webinar on managing requirements in a flexible and agile way. Using the tool Jama as an example they visualized

  • systematic clarification of requirements
  • review and change management of requirements
  • managing requirements in agile context

The focus of the talk was flexible management of requirements. What needs to be done to fully utilize the potential of an RM tool?

Slides of the webinar are available on Slideshare: Flexible and agile management of requirements

User story in Jama

Who Owns the Requirements

When it comes to the question of who owns the requirements the answer is sometimes surprising.

Depending on the titles used in an organization we may hear requirements analyst, business analyst or product manager. Others might name development manager, solution manager or system analyst. While all these people have to say a lot about requirements the product manager should have overall responsibility for the requirements.

Why that? Well, it is the product manager who is ultimately responsible for the business success of the product. He provides product direction and sets the goals for product releases. Through his direct connection to customers and the market he knows best what customer problems are and understands current offerings of competitors. Therefore he is optimally equipped to guide the business team.

Unfortunately, in most organizations the product manager is a poorly defined role. Often product managers get many things to work on, typically too many to be effective. A recent study clearly indicates that product managers work too often on tactical tasks, like customer escalations and supporting sales inquiries.

Successful organizations understand that product management must be balanced between tactical and strategic tasks. However due to the lack of a common understanding of all these tasks it is often a time consuming ineffective effort. Tools that provide an overview of all product management activities accelerate this work substantially.

In October 2010 I gave a presentation at the German “Requirements days” in Munich where I presented some of the fundamental activities in software product management.

Interestingly I got quite some feedback from people, who see a need for clarification specifically in organizations who move towards agile. The simple approach that a product manager equates to a product owner in Scrum doesn’t work out well. On the other extreme product managers might position agile product development to effect only the development organization. They continue to work as before not realizing the full potential of agile development.

Independent whether a software organization works agile or traditional a framework of software product management activities will enable them to improve its effectiveness. That’s why the International Software Product Management Association (ISPMA) pushes towards a certification of software product management.

If this topic is of interest to you, then get in contact with me and/or download the presentation.

Requirements Prioritization

Beyond the Limits of One-Dimensional Lists

Prioritizing requirements for a software release is an activity which frequently crosses the border between science and psychology. The goal is to determine the right set of things to do for a release. For many IT projects this turns out to be a moving target.

In software product development, requirement priorities are set by the product manager. Typically a product manager focuses exclusively on the market need of a requirement and its selling potential. Excellent software companies look at additional factors as well:

  • Cost
  • Risk
  • Fit to product strategy and architecture
  • Ability to deliver

Creating estimates for these factors cannot be done by a single person. Experts from different domains are needed.

There is a couple of techniques available to cope with this issue. Most of them are based on “cost-value” approaches. In my projects, I have applied a variety of them ranging from simple to complex ones. Often we started with something similar to Karl Wieger’s requirements prioritization approach (see www.processimpact.com).

Ultimately, these techniques yield a list of requirements ordered by their relative priority. Such a list is charming because you can always pick the most important requirement next. It is so charming, that this approach has made it into today’s most prominent development approach: Agile methodologies. In agile projects, the term “product backlog” describes a priority-ordered list of work items, which are addressed from top to bottom.

However, there are some shortcomings with these approaches, which need to be overcome in industrial practice. The key problem is the underlying assumption that requirements can be prioritized independently from each other.

Experience shows that this is seldom the case. Most requirements are interdependent from other requirements.

Across many industry domains including software and IT, the fundamental approach to building a system is always the same: A high-level plan is decomposed until the units of work are manageable. Elements of such units share some characteristics. They belong to the same domain and have similar complexity. Rating such elements in relative order works well. However, if the elements are from different domains, you may run into problems: They might have architectural dependencies which cannot be addressed in isolation. Many times, I saw projects getting stuck, because one team was waiting for something that another team had decided to lower in priority.

This problem of deadlock situations can be addressed by explicit dependency management. In requirements engineering, the concept of traceability is used to manage dependent work-items. Directional links express dependency relationships. These techniques exist and are available in most modern requirements management tools. However, in practice, these solutions can be very hard to accomplish, because they require more discipline than most projects are able to bring up.

So I recommend to deploy lightweight traceability using tagging mechanisms at requirements. Sometimes multiple backlogs are used. Each backlog holds items from the same domain. I have seen such approaches working pretty well in many project situations. So they might be the optimal solutions with the right mix of rigor and flexibility.

And don’t forget the importance of communication: Whatever approach one uses, it will be successful only if it is accompanied by good communication structures in the organization.