Agile PDF - Fundamentals Requirements Management

Two types of requirements need to be managed

Functional Requirements

Functional Requirements in the Agile Project Delivery Framework (Agile PDF) are defined just-in-time, rather than
defining all requirements in detail up-front. The reasons are:

Wasted effort is reduced because time isn’t spent early-on defining low-level requirements for everything needed
in the future, which will inevitably change beforehand and need reworking.
Delivery time is maximized for high-value requirements because instead of spending lots time up-front analyzing
all requirements, only those that are needed next are analyzed, therefore shortening the overall time before
development starts on those high-value requirements.

Features, Sub-Features, User Stories, and Technical Tasks

Functional requirements are initially documented as high-level ‘features,' then progressively refined as the project
progresses into ‘sub-features,' and then ‘user stories’ and ‘technical tasks.' Acceptance criteria are then defined against
user stories.

Features are initially identified in the Initiation phase. These are high-level and allow rough sizing and prioritization to
create a high-level release roadmap. During the Foundation phase of a specific release, the features for that release are
re-evaluated and broken down into finer-grained sub-features. Sub-features and the associated features are
documented in a Prioritized Requirement List (PRL) and a revised release roadmap. During the Engineering phase, in
a reasonable amount of time, before a sprint starts, the next highest priority sub-features from the PRL are broken down
into user stories and technical tasks, and their acceptance criteria are defined and agreed upon with the customer. Only
user stories and tasks that are fully prepared can be taken into a sprint.

During each sprint, the user stories are further decomposed into user story sub-tasks and technical tasks into technical
sub-tasks. These sub-tasks represent activities that will be done during the sprint and are documented using an
issue/project management tracking tool, such as Jira.

The following example shows a feature decomposed into sub-features then subsequently user stories, technical tasks
then user story sub-tasks and technical sub-tasks:

The key principle is that Functional requirements are only expanded when needed to provide just enough understanding
so the project team can understand the complexity and dependencies, and can estimate the effort. The approach of
deferring the requirements detail is based on many studies showing that estimates don’t get more accurate after a
certain point. In fact, if requirements are too detailed it takes a lot more effort to estimate because more information
needs to be consumed. This approach balances having enough detail to create appropriately accurate estimates versus
too much detail.

Story Points

Agile methods typically measure effort using a concept called Story Points (SP). Story Points are a pure measure of
relative effort and are highly recommended by Agile PDF instead of estimating using person-days. The purpose of Story
Points is to allow requirements to be easily comparable without needing to know how many people it will take to deliver
them. An alternative estimation method is Ideal Days, however in Agile PDF we will focus on Story Points as an
example, but it’s not mandatory.

Why use Story Points?

We are better at relative estimation than absolute estimation. I cannot tell you how much an elephant weighs,
but I know it weighs more than a horse and less than a whale.

We work at varying speeds. A piece of work that takes you one day might take me two days. If we agree that
that piece of work is 3 SP, then something I think will take me four days will be roughly double that 3 SP, and
you will think it takes two days but still agree that it is double the 3 SP work.

We can get caught up in discussions about how quickly things should take. It is easier to debate whether a user
story is a 3 or a 5 SP story than it is to debate whether something should take 2 or 3 days. A commonly heard
objection might be "it can't possibly take three days to build a foobar!".

It mitigates against expectations of perfect delivery. Things often take longer than we think they will, and there
will be a variance in the time taken to complete tasks. If we communicate estimates to the customer in Story
Points, we avoid setting implicit expectations about the exact time it will take to complete tasks.

We can convert Story Points to person -days. As the project team completes sprints, historical velocity can be
measured. This is the key to using Story Points as you can then make more accurate estimates of future output.
Estimation

Story Points are used to estimate features, sub-features, user stories and technical tasks. Typically when estimating it’s
recommended to use the Fibonacci sequence to reflect the inherent uncertainty in estimating. The rounded Fibonacci
sequence (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) is commonly used in Agile. It reduces the discussion to "is it an 8 or a
13" instead of wasting time differentiating between an 8, 9, 10, 11, 12 and 13.

Features are initially estimated at a high-level during the Initiation phase and usually expressed as a low/medium/high
Story Point value rather than more specific absolute Fibonacci values, to reflect the uncertainty of the estimates. After
the Initiation phase, all estimates are absolute values as requirements should be known with appropriate certainty.

Once you proceed with more precise estimates, during Foundation you can either break features down into smaller
pieces to stay within the Fibonacci range of 0.5-40 Story Points and avoid using the 100 Story Points cards for items
which are more effort than 40, or you deviate from Fibonacci at larger scales, for example, 0, 0.5, 1, 2, 3, 5, 8, 13, 20,
30, 40, 50, 60. Although this not considered standard Agile practice, this allows teams to provide more relevant
estimates and avoid the situation where teams are forced to make something 100 Story Points when in fact they are
closer to 40 Story Points.

During the Foundation phase, the previously estimated features are reviewed and fine tuned as needed, they usually
should not need re-estimating unless something has changed significantly, for example, if the customer changes the
scope or wants to prioritize different parts of the feature. Once the estimations in Foundation are established for a given
release, they act as a project baseline. This Story Point baseline serves as a total estimate of effort for the release.

In Engineering, when splitting features into sub-features, the sub-features are estimated, with the total size equaling the
feature size. The same goes for splitting sub-features into user stories and technical tasks. When user stories and
technical tasks are split into sub-tasks, these sub-tasks are not estimated, as they can easily have 10 or more sub-tasks
and splitting the story points amongst the sub-tasks would be too much administrative overhead and the risk that the
total of all sub-tasks does not equal the parent would be too high.

Velocity

Velocity is the total number of Story Points delivered during a sprint. This is a key metric because it’s used to predict the
number of Story Points a team can deliver over a number of sprints, for example, the estimated number of Story Points
a team can deliver during an Engineering phase consisting of 5 sprints. This estimated Story Point capacity is then used
during Foundation planning to create the release roadmap where features and sub-features are planned for each
release based on the total of their Story Point estimates.

Therefore it’s important to be able to accurately predict the velocity of a team. If the team has already delivered previous
projects using Story Point estimations you can use the team's historical velocity and start from there, assuming the
Story Points have been benchmarked between projects (i.e. a 5 Story Point task is equivalent in both projects).

However, for teams who are new or have never estimated in Story Points, you can only estimate the velocity. For that,
you need to calculate the team’s productivity as the starting point. An individual’s productivity can be calculated through:

Availability
Experience level
Skill-set

There are many resources on the Internet that discuss velocity and how to estimate for new teams. These are general
Agile practices and not specific to Hybris Commerce projects, so we will not discuss it in detail here.

Story Points as Currency

If using Story Points and if used properly, they quickly become the currency of the project. Capacity (total SP) is
estimated for each sprint (measured using velocity) and therefore the total estimated SP for a release can be
calculated. Then anything that requires effort is measured in Story Points and can be tracked during the release so that
effort spent is not lost. This includes requirements as discussed already, but also knowledge transfer, documentation,
and anything else that requires effort from the project team during a sprint. Story Point buffers can then be agreed and
planned ahead of time for each of these non-requirement activities and tracked as appropriate for each sprint/release.

Once Story Points becomes the currency of the project, the customer will start trading SP for changes to requirements
and other activities during the project, swapping in/out items of similar size. For example, Feature A (5 SP) is in scope
for release 1 but now the customer wants to exchange it for Feature B (2 SP) and Feature C (3 SP). This is fine as the
total release SP stay the same, and the 60/40 'must-have'/'should-have' ratio also remains the same after the swap, so
if those 5 SP are must-haves then, the new 2 SP and 3 SP features should also be must-haves (and vice versa).

As another example, instead of swapping Feature A for two other features, the customer might want to spend some
additional effort on knowledge transfer, e.g., to the application management team who will be supporting the solution
after it’s live. The effort for this knowledge transfer is estimated at 5 SP, so it can also be swapped.

While scope swapping within a release is fine, scope swapping within an active sprint is only allowed at the request of
the project team, not the customer, as scope swapping within a sprint is highly disruptive (e.g. new requirement
analysis, defining implementation approach, prepare test data, agree on acceptance criteria etc.).Story Points are a
much more efficient way of managing and communicating effort, rather than the more emotive and less comparative
traditional person-days. Ultimately person-days can always be calculated if necessary, but if done properly most
customers quickly adapt and prefer to use Story Points.

Non-Functional Requirements

Non-functional requirements (NFRs) describe the "constraints", "quality attributes", "quality goals", "quality of service
requirements" and "non-behavioral requirements" of a system. Informally these are often called the "-ilities", and include
requirements related to:

Accessibility
Performance
Scalability
Security
Compatibility
Usability
Maintainability
Portability

Unlike functional requirements, these must always be fully elaborated and signed-off up-front during the Foundation
phase together with their acceptance criteria, then only changed if required during the Engineering phase using a more
rigorous change control process. It’s not easy to swap or change NFRs like with functional requirements. This is
because unlike functional requirements, NFRs need to be fully known up-front before Engineering starts as they have
an immediate and direct impact on the solution architecture and design, which are very difficult and expensive to
change later.

For example, there is a very significant difference between a system that needs to support 10-page impressions per
second (pi/s) vs. 100pi/s. Not only will this impact software architecture, but also the production infrastructure, which will
also have a significant impact on the overall cost. All of which must be identified and known by the end of the
Foundation Phase.

See also Non Functional Requirements.