• About me

    JensI have been working as a software consultant for more than 11 years. Because of that I am an eager supporter of lean principles and agile methods.

  • Recent Posts

  • Recent Comments

    • ankara evden eve nakliyat: i have one of this quaker oats from taiwan but i dont know how to cook it. Mary...
    • Engineering CV: You did make a brave move..in this downtime economic crisis. Best wishes for your new job!
    • lazer epilasyon: A blog post was really useful, you can not find the information sought in a lot of places I’ve...
    • one minute left: not be published) (required) Website. Subscribe to comments feed. What do the extreme left and...
    • joseph pelrine: I will have to watch that as I’m a big fan of his because of the unique perspectives he brings....
  • Archives

  • Blogroll

  • Meta

Capturing requirements in large “non-agile” enterprises seem to follow a common template:

  • Business stakeholders are anxious to catch all of their known requirements into the first release.
  • Users generate hundreds of detailed requirements that often bear little relationship to the business problems that need to be addressed.
  • Most requirements are given the highest priority.
  • Requirements are signed off before handed over to design and implementation.
  • The requirements represent today’s view, which will most certainly have changed by the time all requirements are implemented.

In Methods & Tools’ latest newsletter Ian Evans shares his experiences on Agile Delivery at British Telecom, where he addresses the problem above as well as other problems related to agile adoption at an enterprise level.

Something to say?

Bloggtoppen.se