Agile Development at HP - Part 4: Feature and User Story Lifecycles

This is the fourth in a series of five posts that describe the methodology and development processes used by the HP Agile Manager team.  In the first post, I described how we came up with our development processes. In the second post, I discussed the culture and values of the team, and how we maintain a consistently high level of quality. In the most recent post I explained the release and sprint lifecycles.  This post talks about the feature and user story lifecycles.  The final post will summarize the roles and responsibilities of each member of the team

 

Features and User Stories

The feature lifecycle describes how a feature is created, from the design stage to the implementation of all of its user stories, and incorporates feedback from production. A user story’s lifecycle starts with its design and development, including testing, and is complete when the functionality and code have been reviewed, and all tests pass.  Let’s look at these two lifecycles in detail.

 

Feature Lifecycle

There are four main stages in the lifecycle of a feature:

p1.png

 Each feature has an overall owner: the Feature Lead. The Feature Lead is always held accountable for the feature over its lifecycle, and it is their responsibility to handle anything that might impede the feature’s progress.  Examples include:

 

  • Escalating the problem to the relevant stakeholders
  • Putting more pressure on people who might be holding up progress (for example, the architects, who need to deliver their functional or system designs in time)
  • Delegating issues to someone else to ensure they are handled
  • Assuming direct responsibility over an issue if there is no other option

Nevertheless, many roles are involved in each of the stages of a feature’s development. Let’s look at these stages in detail.

 

Feature Design

To make sure there’s enough time for the feature’s design, we start the design at least one sprint prior to its implementation.  .  The scope of each feature is kept to the smallest set of functionality that provides value to the customer, or Minimally Marketable Feature (MMF).  Here are the tasks that need to be done to ensure a complete feature design:

 

Task

Responsibility

Functional design

Functional Architect (FA)

Prepare mockups

User Experience Expert (UX), FA

Graphic design

UX, Graphics Designer

Technical research and design

System Architect (SA), Team Leads, Security Officer, QA Engineer (Performance)

User story breakdown

FA

User story prioritization within the feature

FA

Acceptance tests

FA, QA Team Leader

Time estimation of the user stories

Team Leads

Re-ranking and re-prioritizing due to revised time estimates

FA, SA

Strings

Information Engineers (Docs)

 

We usually perform a feature design review before we start implementing it, to make sure that all stakeholders understand and agree on the feature’s scope, priority and design.

 

Feature Implementation

The actual code is written during the implementation phase.  But a lot more than simply writing code goes into a feature’s implementation:

 

Task

Responsibility

Write the code

Developer

Document the feature

Docs, FA

Polish the UI

Docs, FA, Developer

Testing

QA Engineer

Update test automation

QA Engineer, Developer

Ensure existing features and data can be upgraded

Developer

Expose monitors (usage, performance, log, etc)

Developer, SaaS Operations

Update demo data where applicable

FA, Developer

 

Once the implementation is completed, the feature enters the ‘Feature Complete’ stage.

 

Feature Complete

Although this sounds more like a milestone, it is actually a stage. A feature can only be considered complete when the following tasks have been completed:

 

Task

Responsibility

Feature review

FA, UX, QA Engineer, Docs

Definition of Done is reached

FA

Supporting material is ready (release notes, documentation, feature movie, training)

FA

Technical debriefing

Developer

Security review

Security Officer

 

Once the feature is complete, it is rolled out to production.  Once it has been deployed, the Production Feedback stage is entered.

 

Production Feedback

It’s vital for us to get users’ feedback about the feature, either directly through support cases and log analysis, or indirectly through performance and usage statistics.  We use the feedback to guide further development of the feature. 

 

Here are the steps involved: 

 

Task

Responsibility

Usage Research

FA

Performance impact research

Developer, SA, QA Engineer (Performance)

Feedback collection

FA

Support case analysis

FA

Log analysis

Developer

Security feedback

Security Officer

Backlog enhancements

FA

Re-scope and prioritize backlog

FA

 

User Story Lifecycle

A user story is a basic action that a user should be able to carry out in the application.  We manage our user stories in HP Agile Manager, and during development, each user story goes through the following stages:

 p2.png

 Unlike features, which are owned by a feature lead throughout their lifecycle, each stage in the life of a user story has a different owner.  Let’s drill down into each of these stages.

 

New User Story

A new user story needs to be designed, both from a functional and technical perspective. The Functional Architect is typically the owner of the new user story.  Here are the tasks that are performed on a new user story:

 

Task

Responsibility

Functional specification

FA

Mockup review

Developer Team Leader, Developer, QA Engineer

Technical design

Developer

 

Once a user story has been assigned to a sprint backlog, development can begin, and it is moved to an ‘In Progress’ status.

 

In Progress

Developers are responsible for user stories that are ‘In Progress’.  Once development has begun, the following tasks are also performed:

 

Task

Responsibility

Acceptance tests written

QA Engineer, Developer

Automated acceptance tests defined

QA Engineer, Developer

Analysis of related technical backlog items that may cause regression

Developer, QA Engineer

Analysis of related backlog items that need an upgrader, and for which covering tests need to be written

Developer, QA Engineer

 

Once a user story has been developed, it needs to be tested.

 

In Testing

QA Engineers are responsible for ‘In Testing’ user stories. But in order for a user story to be changed to ‘In Testing’, certain criteria must be met. These criteria are actually the domain of the developer:

 

Task

Responsibility

User story is testable

Developer

Code is reviewed and checked in

Developer

Automated tests checked in

Developer

(Textual) JBehave tests are written

QA Engineer

 

Once the QA engineer is sure that a user story has been tested, it is marked ‘Done’.

 

Done

A user story can only be marked ‘Done’ when all of the following criteria have been achieved:

 

Task

Responsibility

Functional and usability review

Functional Architect, Usability Expert

All automated tests (acceptance, unit, integration) pass

QA Engineer

Acceptance tests pass

QA Engineer

Regression and upgrade tests pass

QA Engineer

 

Thanks for following this series of posts on how HP uses Agile methodologies. Leave us a comment in the box below to let us know how you use Agile methodologies in your organization.

 

If you are looking to read more about this topic, feel free to read the other topics in this series:

 

 

In the next, and final, part in this series, we’ll summarize the different roles and their responsibilities throughout the development lifecycle.

 

This series of articles was written based on processes and methods developed by Lihi Elazar (Agile Manager PMO) and materials provided by her.  Thanks to both Lihi and to Asi Sayag (R&D Group Leader), for their help, guidance, and extensive reviews of this series.

Comments
MikeCarew | ‎10-03-2014 02:05 AM

We always use a ready check for features and stories to ensure that they are ready for the implementation stage. This is in addition to reviews. Do you use such a check?

Lihi | ‎10-06-2014 02:27 AM

Yes, we perform a feature design review before we start implementing it, to make sure that all stakeholders understand and agree on the feature’s scope, priority and design.

| ‎11-15-2014 12:22 AM

Great article. Can't wait for the next one.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.