Managing Agile Requirements

Document Sample
Managing Agile Requirements Powered By Docstoc
					Managing Agile Requirements




Mia McCroskey
February 22, 2011
Background

Presenter and Organization

 Mia McCroskey
    Requirements manager, quality assurance manager, and project
     manager at Emerging Health Information Technology
    Certified Project Management Professional
    Certified SCRUM Master
    Eleven years in requirements engineering and project management

 Emerging Health Information Technology
    Healthcare professional services and consulting firm
    Subsidiary of Montefiore Medical Center, Bronx, New York
Background

Product and Industry

 Clinical Looking Glass Product
       Web-based application
       Accesses the electronic medical record
       Places patient data analytics in the hands of clinicians
       Developed by medical informaticists over ten years

 Health Care Information Technology
       Electronic medical record puts spotlight on informatics
       Health Information Portability and Accountability Act (HIPAA)
       National mandate to prove meaningful use of patient data
       Quality improvement initiatives
Background

Clinical Looking Glass Team

 Seventeen engineers, testers, analysts, and managers
 Each wears several “hats”
 Research and development mentality
 Strong ALM processes and best practices
 Growing focus on usability
 Strong support for cutting edge and industry standard technologies, tools,
  and processes
 Introduction of new technology (e.g., Silverlight) for new modules creates
  dissonance with earlier portions of the application
 Internal shop – do not need detailed specifications approved by an
  external client
    This Iteration


 Background
 Agile overview
 Requirements in Sheep’s Clothing
 Requirements in Our Bones
 YAGNI – You Ain’t Gonna Need It
 Agile Requirements Lifecycle
 Practical Examples
 Conclusions
Agile Overview

The Agile Manifesto

           Individuals and Interactions over processes and tools
           Working software over comprehensive documentation
             Customer collaboration over contract negotiation
                Responding to change over following a plan


                       “Favor the left over the right”
                              does not mean
                      “don’t do the stuff on the right”
Agile Overview

Agile Requirements

Good User Stories Are
•   Independent
•   Negotiable
•   Valuable
•   Estimable
•   Small
•   Testable




                        Requirements Roles
                        •   Product Owner
                        •   Business Analyst
                        •   Stakeholder
                        •   Team Member
    This Iteration


 Background
 Agile overview
 Requirements in Sheep’s Clothing
 Requirements in Our Bones
 YAGNI – You Ain’t Gonna Need It
 Agile Requirements Lifecycle
 Practical Examples
 Conclusions
Requirements in Sheep’s Clothing


NUMB3RS

 15 Sprints
 99 User Stories
 1318 Sprint Tasks
 620 Requirements
 21 Standards and Guidance Documents
Requirements in Sheep’s Clothing

Scenario 1
Spring 2009: CLG Goes Agile!
Fall 2009: “What did we decide to do about allowing a ‘WITHIN’ condition to
be used as a user-defined duration when browsing results data?”
By sprint three team members could not recall specific rules and
requirements implemented as recently as sprint one.
Requirements in Sheep’s Clothing

Scenario 1
SCRUM Coach: Review the conditions of acceptance in the completed
Product Backlog Items
TEAM: There are so many!
TEAM: I’m not sure which sprint it was
TEAM: This level of detail wasn’t specified in the conditions of acceptance!
SCRUM Coach: Review the test cases.
TEAM: Which test cases? There are dozens.
TEAM: And why do I have to derive the requirement from the expected
results?
TEAM: What if I misunderstand the intent?
Requirements in Sheep’s Clothing


Scenario 2
During the fifth sprint, a user story introduces functionality that includes
display of patient data
HIPAA rules apply, which are covered by the Security Audit Inventory,
a standards document
Product owner does not include the existing security function in the
conditions of acceptance
     Why should he? It’s a standard.
Mid-sprint the team realizes they didn’t include it in estimation or planning
Renegotiate with product owner
Requirements in Sheep’s Clothing


Scenario 2
Why was it omitted?
    The HIPAA function already exists so it’s “off the radar”
    Business analysts failed to think “big picture”
    Team members did not review the standards
    Pressure to keep PBIs small can result in conscious and unconscious
     deferral of critical requirements
    User stories are supposed to be independent – discourages integrated
     analysis
Requirements in Sheep’s Clothing


The agile model relies on the
teams’ adherence to pre-defined
standards.
User story need not state anything covered
in the standards:
      User Interface
      Quality of Service
      Security
      Technology
The definition of done
      Is a form of
        requirement spec
      Refers to many
        additional standards
        documents
   Requirements in Sheep’s Clothing
 Every Sprint Backlog Item is (supposed to be) reviewed by the team for compliance with appropriate
 standards before it’s considered “done.”

 CLG standards and guidance artifacts created or expanded during sprint 0
                                          Definition of Done
 Global Quality of Service Requirements                                 Client Technology Stack
      Scrum Test Practices                              Development Technology Stack
                                  Unit Test Targets                            Server Environments
  CLG Personas
                        Code documentation standards
 SQL Server Coding Standards                     Security Development Lifecycle process
          DB Pro Implementation Guidelines                               Security Audit Inventory
                                                                                      Product Vision
    Code analysis rules                            User Interface Standards

 Smoke Tests Standards and Guidelines                Release Management Process
                                                  Required UML                 Management Metrics
      Architecture Guidelines                                                                   www.freefoto.com
    This Iteration


 Background
 Agile overview
 Requirements in Sheep’s Clothing
 Requirements in Our Bones
 YAGNI – You Ain’t Gonna Need It
 Agile Requirements Lifecycle
 Practical Examples
 Conclusions
Requirements in Our Bones


Solution Strategies for Standards Ignorance
Each team member tends to know some of the standards
Develop practice of having standards “experts” review work before calling it
done (Agile? Not so much…)
Scrum masters continually remind the teams to double check the standards
Reduce the number of standards – focus on the ones that really matter and
are achievable
Eventually standards are absorbed into the bones of the team
Then allow the team to expand them as practices catch up with goals
Requirements in Our Bones


Agile Standards Evolution
Developing a new module with similar functionality to existing modules
The state of some controls is not intuitive under existing UI standards:
     The buttons in the existing modules appear “greyed
       out” unless you mouse over them




     In the new module, the product owner
      specifies “active looking” controls



The UI standard is revised
Requirements in Our Bones


Agile Standards Evolution: The Fallout
    Must live with the inconsistency between old and new modules until
     the old module is updated
        Undermines the value of standards
    Team might defer update of the old module even when they’re working
     on it for other reasons
        If they wait for the user story to fix this issue they’ll get credit for
         business value
        If they do it when they’re in that part of the code for another
         reason, it’s a freebie
    This Iteration


 Background
 Agile overview
 Requirements in Sheep’s Clothing
 Requirements in Our Bones
 YAGNI – You Ain’t Gonna Need It
 Agile Requirements Lifecycle
 Practical Examples
 Conclusions
YAGNI – You Ain’t Gonna Need It


Only document what you need when you need it
No more specifications!
No more sequence diagrams!
No more prototypes!
Just code it and demonstrate it!




                                      Woohoo!
                                    It’s 1983 all over again!
YAGNI – You Ain’t Gonna Need It


What YAGNI Really Means to Requirements
Embrace “Just in Time”
Admit that those thick requirements specs were never complete
or correct
Be as loyal to your requirements standards as you are to your other
“definition of done” standards
     But first, modify your requirements standards for agile
Capture decisions as they are made
    If you are fundamentally opposed to calling such decisions
      “requirements” then don’t. But still capture them.
YAGNI – You Ain’t Gonna Need It


What Requirements Do You REALLY Need?
Use Cases?
Functional Requirements?
System Requirements?
Business Rules?
System Interface Requirements?
User Interface Requirements?
“-ility” Requirements?
YAGNI – You Ain’t Gonna Need It


What Are Agile Requirements For?
Team memory
      So team members can find information about work done in previous sprints
       without having to dig through stacks of “done” user stories

Product owner/business analyst memory
      To inform the creation of new user stories

User documentation and training material development
YAGNI – You Ain’t Gonna Need It


What Is Covered by Standards?
User Interface Requirements – User Interface Standards
      This standard evolves as you develop new portions of your application.
      Team is responsible for
          Revising it based on successfully completed new interfaces
          Knowing when to apply the existing standard
          Knowing when to challenge a user story that specifies a standards violation

“-ility” Requirements – Quality and Performance Standards
      Performance goals may be included in user stories
      When the story is completed, this standard is updated and the newly delivered
       performance is now required
      Team is responsible for maintaining benchmarks and measuring against standard
       in every sprint – really need automated tests
YAGNI – You Ain’t Gonna Need It


Get Rid of What No Longer Serves You
Do you really need to specify for each new screen that
    “The system shall provide a means for the user to reset
     all data fields,” and
    “The system shall provide a means for the user to save
     entered data,” and
    “The system shall validate all user entries upon save”?



                                   No
YAGNI – You Ain’t Gonna Need It


Get Rid of What No Longer Serves You
Do you still need use cases?
     Have the business analyst draft test cases instead – the same logical
      exercise results in a usable artifact

Rules rule
     Rules are the application’s code of conduct
     The customer is more concerned about how the application arrives at a
      decision than about the order of button presses to get their answer
      (but you should worry about that in your usability and user interface
      standards)
     Capture rules based on the user story conditions of acceptance, and
      throughout each sprint as decisions are made
YAGNI – You Ain’t Gonna Need It


User Story Test Criteria
The acceptance criteria
specified by the product owner
are usually high level business
requirements
    Don’t automatically capture
     them, whole cloth, as
     requirements
    The BA on your team
     should analyze and
     decompose them –
     and will likely find
     holes and conflicts
    This Iteration


 Background
 Agile overview
 Requirements in Sheep’s Clothing
 Requirements in Our Bones
 YAGNI – You Ain’t Gonna Need It
 Agile Requirements Lifecycle
 Practical Examples
 Conclusions
Agile Requirements Lifecycle


Out of Sync with Iterations
Six months in advance
    Decompose high level business goal into epics

A couple months ahead of the sprint
      Decompose epics into user stories
      Prioritize
      Gather critical acceptance criteria
      Gather externally driven rules




                                                 www.freefoto.com
Agile Requirements Lifecycle


Before Sprint Kickoff
Test user stories and acceptance criteria for
compliance with INVEST
     Analyze impact of this work on other user stories slated
      for the same sprint (Independent)
     Review with team, repackage (Negotiable)
     Assign business value (Valuable)
     Allow entire team to estimate (Estimable)
     Re-scope if estimate is too high to complete in a sprint (Small)
     Review acceptance criteria for testability (Testable)
Agile Requirements Lifecycle


During the Sprint
Convert story into high level business requirement
Convert acceptance criteria into functional
requirements and rules
Derive and capture additional rules
and requirements
Verify new rules and requirements with
team and product owner                                      www.4freephotos.com


Watch for additions to standards and conflicts with them
Agile Requirements Lifecycle


Scope Creep
Adding new requirements to the user story as acceptance
criteria has impact
    The acceptance criteria are a contract between the team
     and product owner
    Adding new ones gives the team the right to re-estimate
       If the team determines that a requirement surfaced during
        the sprint substantially changes the scope of the user story,
        then they should re-estimate
       If the requirement simply clarifies or refines the story,
        they should absorb it into their work
Agile Requirements Lifecycle


What you Need to Write Down
Capture the critical requirements in a functional
model
     Remember how our team couldn’t remember
      what they did two sprints back, and finding it in
      the user story/acceptance criteria was a
      daunting task?
         Functionally organized requirements are
          easier to use
                                                          www.commons.wikimedia.org
         Testers can use the trace matrix to see
          whether test plans sufficiently cover
          functional areas of the application
         Reinforces with the team the user
          perspective of the application
Agile Requirements Lifecycle


The Trace Matrix
May have to traverse tools
     Our requirements model is in IBM Rational DOORS
     The rest of our work is managed with MS Visual Studio/Team
      Foundation Server
Remember the primary intent of the matrix – are all the business
requirements tested?
Trace current manual tests of new functionality
Don’t get hung up on managing the detailed trace to automated regression
tests – unless your tooling does it for you
Agile Requirements Lifecycle


The Trace Matrix
Global business rules and
requirements trace across
applications to User Story
In DOORS, granular
business rules and functional
requirements trace to global
In MS VS, test cases trace
to user story
    This Iteration


 Background
 Agile overview
 Requirements in Sheep’s Clothing
 Requirements in Our Bones
 YAGNI – You Ain’t Gonna Need It
 Agile Requirements Lifecycle
 Practical Examples
 Conclusions
Practical Examples


Requirements Management
In DOORS, custom views support
granularity
    Filter requirements for the specific
     application area
    Reduce noise for team members working
     on user stories in specific areas

Release-based views inform quality
assurance efforts
    Identify all requirements included
     in the release
Practical Examples


Functional View vs Sprint View
                                  Functional requirements module
                                   puts all related requirements
                                   together regardless of when they
                                   were implemented
                                      Supports business analysis,
                                       regression testing, user training



 Sprint view in MS VS and the team
  task board focuses the team on
  what they are doing now
    Supports the day-to-day life of the
     scrum team
Practical Examples


Global Requirements, Area View
Filter the requirements model to see only the requirements related to a
specific functional area
Includes user
story references,
release to
production, and
release to users
Practical Examples


Functional
Requirements
Filter for specific area
Shows release to
production
Trace to business rules
Trace to global
requirement and user
stories
Shows release of global
requirement to users
Practical Examples


Business Rules
Includes trace from functional requirement and area of that requirement
(rules can apply to more than one area)
Reveals lifespan
and churn of the
rule – all
releases with
changes that
referenced it
Practical Examples


The User Story
Formal rules buried in
acceptance criteria
are recorded in the
business rules
Practical Examples


The User Story
Hyperlinks on the user story allow team members to quickly access related
granular requirements
    This Iteration


 Background
 Agile overview
 Requirements in Sheep’s Clothing
 Requirements in Our Bones
 YAGNI – You Ain’t Gonna Need It
 Agile Requirements Lifecycle
 Practical Examples
 Conclusions
Conclusions


 Sweat the requirements details when they arise, in context, and
  with a well-informed team and product owner
     No more re-baselining requirements
 Business analysts have more time to analyze the critical
  requirements
     Deep dive only on the complex stuff
     Deep dive right before and at the start of the sprint
 Engineers identify important requirements during design
  and coding
     Document in requirements model
     In the past, if they found a hole they might just do what they
      thought best
Conclusions


 Lighter requirements model is easier to maintain
 Shift away from functional detail to business priorities
     Team understands business drivers
     Less engineering for engineering’s sake
     Fewer requirements for requirements’ sake
          Pre-agile requirements were 21% of total effort
          SCRUM requirements are 9% of total effort
Questions?

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:20
posted:6/6/2012
language:English
pages:48