Requirements: derive from goals, capture and manage flow

Manage Requirements Flow

Agile teams need a continuous stream of requirements to maintain pace and flow. New scope is derived frequently from goals and feedback to previous product increments. Requirements are not “handed-over” but collaboratively refined just-in-time for implementation.

Together with the team, the product owner (business analyst, requirements engineer, …) needs to setup and manage a pipeline for refining this stream of requirements.

Classical requirements management tools are not optimized for managing this flow. Their intended usage is that a business analyst pushes “complete” specifications to the team for implementation. These tools are optimized for creating and managing large amounts of requirements that are eventually handed over to the team.

SpecLog is optimized for continuous collaboration with the team on managing and refining newly identified requirements:

• Workspaces, similar to story maps, can be used to arrange and visualize maps of requirements for different planning aspects and levels of maturity or understanding.
• Tags can be used to manage the flow of requirements through the refinement pipeline.
• Refinements and dependencies of requirements can be tracked and visualized on the workspace. (*)

Derive Scope from Goals

“Successful problem solving requires finding the right solution to the right problem. We fail more often, because we solve the wrong problem than because we get the wrong solution to the right problem.” (Russel Ackoff, 1974)

Unfortunately, most of the software development projects we are dealing with are so called “wicked problems”, where the definition of the problem changes with the point of view from different stakeholders, and also over time. Since the problem cannot be described definitely, there is also no point in describing a definite solution. Instead you need to optimize the solution until it is “good-enough” from all involved perspectives.

Agile projects continuously strive for optimizing the scope to reach “good-enough” solutions. They try to identify key stakeholders and their goals, and then derive useful scope to implement for supporting these goals.

There are different methodologies in agile product planning that help with deriving scope from goals. Some of them are:

• Effect maps break down high level business goals into individual goals of actors and stakeholders and are used to derive scope from these individual goals.
• Story maps can be used to visualize and manage parts of a product backlog according to a specific aspect such as roadmaps, a concrete actor goal or a minimum marketable feature set (or walking skeleton) of the product.

SpecLog is designed to build and maintain the product backlog as more than just a list of epics and user stories:

• Workspaces can be used to arrange requirements (such as user stories) like in story maps or effect maps. Users can share and collaborate on these maps through SpecLog.
• Relationships between requirements can be visualized on the maps.
• Searches in requirements can be visualized on the maps.
• The structure of requirements can be customized for different goal levels and styles.

Capture User Stories

Requirements are captured at different goal levels in agile projects:

• Business goals define the measurable business effects a system should enable, facilitate or support.
• Actor and stakeholder goals define how individuals are working towards achieving these business goals.
• Epics, themes and user stories are describing features of a system that are supporting a specific actor or stakeholder goal.
• Acceptance criteria finally describe how a specific user story should be implemented through a series of small acceptance tests that can be verified by business.

SpecLog supports capturing requirements in different formats that suit best for your team:

• Requirements can consist of actor, goal, value and title.
• Templates can be specified for different kinds of format and language of requirements (e.g. “As a I want to so that “, “In order to , as a , I want “, …).
• Multiple templates can be defined for different goal levels and purposes.
• Acceptance criteria can be captured for refining requirements before implementation.