1. Enrique Lima
Pinnacle of Indiana
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 all start 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 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.

8. 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

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