Enrique Lima
Pinnacle of Indiana
elima@pinnacleofindiana.com

Twitter: @enriquelima
   Enrique Lima
   elima@pinnacleofindiana.com
   Senior Developer
   Pinnacle of Indiana
   Microsoft Community Contributor
   Member of the Geekswithblogs.net Community - Influencer
     http://geekswithblogs.net/enriquelima
   @enriquelima - twitter.com/enriquelima
   Member of INETA
•   Stop asking questions, just build the thing
    already.
•   Of course I am sure what I want
•   No, no need to document it, we are set on
    what we want
•   Change our mind? US?!? No, never!
•   Any and all comments similar to your reality
    are … pure coincidence!
•   Otherwise it would just be weird
•   Being Agile, and what that means
•   Requirements Management Defined
•   What defines the vision?
•   How do we make it our mission?
•   Validation and verification
•   Measuring success
•   Tools and Styles
It should all start with an idea!




                                                  It’s just that simple … we are done!


                      You are not paid to think! You are paid to do!
   Agile vs. agility
   Agile never said “Do not document”
   Agile does not say “Requirements? We don’t
    need them”
   Agility gives you the flexibility to change
   Agile gives you the methodology to drive and
    monitor that change
The process of documenting, analyzing, tracing,
prioritizing and agreeing on requirements and
then controlling change and communicating to
relevant stakeholders. It is a continuous process
throughout a project. A requirement is a
capability to which a project outcome (product
or service) should conform.
Someone, somewhere decided that either you apply Agile literally or
you are not agile. Some other dude, in some other place decided if
you document then you are not Agile.


They want to increase traceability, yet …
We should not document, documentation is tedious
and unnecessary.
                             Is It???!!!???




         Gathering or eliciting requirements is essential to know where we are
         going, what is needed, what needs to be satisfied
   EPICs, stories
   Requirements
   Help define what the
    client/customer/stakeholder will be
    accepting.
   Be a CSI                           Think outside the Box
     Investigate                        Design


   Adopt a can do                     Always wear a hard hat
    attitude                             Construct and test
     Feasibility and flexibility
                                       Master your trade
   Celebrate your victory               Trade-off that is
     Release
   Make it EPIC!
   Be able to make it smaller and attainable
   “Aim small, miss small“
   Become a story teller
   Identify a clear and concise story
   Know thy path!
   Tell me about how you like your Peanut
    Butter and Jelly sandwich

   Use Ron Jeffries’ three Cs
     Card
     Conversation
     Confirmation
   The EPIC grand tale becomes a Story
   Turn the story to an action
   Measurable stories
   Stories become a detailed task

   Give them weight!
   Learn to play Poker.
   0,1,2,3,5,8,11,20 …
   The Power of the Card!
   Manage Progress!
   Manage Change!
   Wait, this sounds like a contract!
   Involve, engage, commit!
   Reach and achieve MVF!!!
   Know where you are going
   Know how to get there
   Know when you have arrived
   Receive “the reward” for having arrived.

   Building the right solution is not the same as
    building the solution right
   Was the goal to …
     Get there?
     Get there fast?
     Get there with time left on the clock?
     Get there before anyone else?
     Get there somehow?


     Wash, Rinse, Repeat.
   Electronic or Hardcopy?
     CaseComplete
     AgileZen
     Pivotal Tracker
     VersionOne
     Combination?
      ▪ TFS
      ▪ SharePoint
   Would it help deliver better solutions?
   What about adoption?
   Remember    MVF
   http://www.pinnacleofindiana.com
   http://geekswithblogs.net/enriquelima
   http://www.casecomplete.com/
   http://21scrum.com
   Visual Studio ALM Rangers
       http://msdn.microsoft.com/en-us/vstudio/ee358787

Requirements Management - CodepaLOUsa

  • 1.
    Enrique Lima Pinnacle ofIndiana elima@pinnacleofindiana.com Twitter: @enriquelima
  • 2.
    Enrique Lima  elima@pinnacleofindiana.com  Senior Developer  Pinnacle of Indiana  Microsoft Community Contributor  Member of the Geekswithblogs.net Community - Influencer  http://geekswithblogs.net/enriquelima  @enriquelima - twitter.com/enriquelima  Member of INETA
  • 3.
    Stop asking questions, just build the thing already. • Of course I am sure what I want • No, no need to document it, we are set on what we want • Change our mind? US?!? No, never! • Any and all comments similar to your reality are … pure coincidence! • Otherwise it would just be weird
  • 4.
    Being Agile, and what that means • Requirements Management Defined • What defines the vision? • How do we make it our mission? • Validation and verification • Measuring success • Tools and Styles
  • 5.
    It should allstart with an idea! It’s just that simple … we are done! You are not paid to think! You are paid to do!
  • 6.
    Agile vs. agility  Agile never said “Do not document”  Agile does not say “Requirements? We don’t need them”  Agility gives you the flexibility to change  Agile gives you the methodology to drive and monitor that change
  • 7.
    The process ofdocumenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform.
  • 8.
    Someone, somewhere decidedthat either you apply Agile literally or you are not agile. Some other dude, in some other place decided if you document then you are not Agile. They want to increase traceability, yet … We should not document, documentation is tedious and unnecessary. Is It???!!!??? Gathering or eliciting requirements is essential to know where we are going, what is needed, what needs to be satisfied
  • 10.
    EPICs, stories  Requirements  Help define what the client/customer/stakeholder will be accepting.
  • 12.
    Be a CSI  Think outside the Box  Investigate  Design  Adopt a can do  Always wear a hard hat attitude  Construct and test  Feasibility and flexibility  Master your trade  Celebrate your victory  Trade-off that is  Release
  • 13.
    Make it EPIC!  Be able to make it smaller and attainable  “Aim small, miss small“  Become a story teller  Identify a clear and concise story  Know thy path!
  • 14.
    Tell me about how you like your Peanut Butter and Jelly sandwich  Use Ron Jeffries’ three Cs  Card  Conversation  Confirmation
  • 16.
    The EPIC grand tale becomes a Story  Turn the story to an action  Measurable stories  Stories become a detailed task  Give them weight!  Learn to play Poker.  0,1,2,3,5,8,11,20 …
  • 17.
    The Power of the Card!  Manage Progress!  Manage Change!  Wait, this sounds like a contract!  Involve, engage, commit!  Reach and achieve MVF!!!
  • 18.
    Know where you are going  Know how to get there  Know when you have arrived  Receive “the reward” for having arrived.  Building the right solution is not the same as building the solution right
  • 19.
    Was the goal to …  Get there?  Get there fast?  Get there with time left on the clock?  Get there before anyone else?  Get there somehow?  Wash, Rinse, Repeat.
  • 20.
    Electronic or Hardcopy?  CaseComplete  AgileZen  Pivotal Tracker  VersionOne  Combination? ▪ TFS ▪ SharePoint
  • 21.
    Would it help deliver better solutions?  What about adoption?  Remember MVF
  • 22.
    http://www.pinnacleofindiana.com  http://geekswithblogs.net/enriquelima  http://www.casecomplete.com/  http://21scrum.com  Visual Studio ALM Rangers  http://msdn.microsoft.com/en-us/vstudio/ee358787