Software Developers
Showing results for 
Search instead for 
Do you mean 

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

Anonymous_User1 ‎12-03-2013 10:00 AM - edited ‎08-05-2014 05:35 AM

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:

 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:




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


User story prioritization within the feature


Acceptance tests

FA, QA Team Leader

Time estimation of the user stories

Team Leads

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



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:




Write the code


Document the feature

Docs, FA

Polish the UI

Docs, FA, Developer


QA Engineer

Update test automation

QA Engineer, Developer

Ensure existing features and data can be upgraded


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:




Feature review

FA, UX, QA Engineer, Docs

Definition of Done is reached


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


Technical debriefing


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: 




Usage Research


Performance impact research

Developer, SA, QA Engineer (Performance)

Feedback collection


Support case analysis


Log analysis


Security feedback

Security Officer

Backlog enhancements


Re-scope and prioritize backlog



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:


 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:




Functional specification


Mockup review

Developer Team Leader, Developer, QA Engineer

Technical design



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:




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:




User story is testable


Code is reviewed and checked in


Automated tests checked in


(Textual) JBehave tests are written

QA Engineer


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



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




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.

About the Author


on ‎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?

on ‎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.

on ‎11-15-2014 12:21 AM
on ‎11-15-2014 12:22 AM

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

Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all