Requirements Management - CodepaLOUsa


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Requirements Management - CodepaLOUsa

  1. 1. Enrique LimaPinnacle of Indianaelima@pinnacleofindiana.comTwitter: @enriquelima
  2. 2.  Enrique Lima Senior Developer Pinnacle of Indiana Microsoft Community Contributor Member of the Community - Influencer  @enriquelima - Member of INETA
  3. 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. 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. 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. 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. 7. The process of documenting, analyzing, tracing,prioritizing and agreeing on requirements andthen controlling change and communicating torelevant stakeholders. It is a continuous processthroughout a project. A requirement is acapability to which a project outcome (productor service) should conform.
  8. 8. Someone, somewhere decided that either you apply Agile literally oryou are not agile. Some other dude, in some other place decided ifyou document then you are not Agile.They want to increase traceability, yet …We should not document, documentation is tediousand unnecessary. Is It???!!!??? Gathering or eliciting requirements is essential to know where we are going, what is needed, what needs to be satisfied
  9. 9.  EPICs, stories Requirements Help define what the client/customer/stakeholder will be accepting.
  10. 10.  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
  11. 11.  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!
  12. 12.  Tell me about how you like your Peanut Butter and Jelly sandwich Use Ron Jeffries’ three Cs  Card  Conversation  Confirmation
  13. 13.  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 …
  14. 14.  The Power of the Card! Manage Progress! Manage Change! Wait, this sounds like a contract! Involve, engage, commit! Reach and achieve MVF!!!
  15. 15.  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
  16. 16.  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.
  17. 17.  Electronic or Hardcopy?  CaseComplete  AgileZen  Pivotal Tracker  VersionOne  Combination? ▪ TFS ▪ SharePoint
  18. 18.  Would it help deliver better solutions? What about adoption? Remember MVF
  19. 19.  Visual Studio ALM Rangers 