Showing posts with label manifesto. Show all posts
Showing posts with label manifesto. Show all posts

Sunday, March 1, 2015

BRD, Requirements Document in Agile Scrum?

While comprehensive documentation is valuable, a working software is MORE valuable as per the Agile Manifesto. One of the myth about Agile Scrum is that it promotes no documentation. The fact is that documentation is certainly not a bad thing, but Agile suggests to create minimum required documentation.

So the question is where do you keep user requirements - trying to find something similar to BRD (Business Requirements Document) in Agile?

The answer is rather simple - "product backlog"! Product backlog is only place to capture all the user requirements and as we know these requirements are prioritized by product owner for each release, sprint and is called release backlog and sprint backlog respectively.

Pic: 1) Product Backlog, 2) Release Backlog, 3) Sprint Backlog

You may also want to check this post to learn more about difference between terms Release, Sprint.

Sunday, March 3, 2013

Waterfall Manifesto

Take a break from Agile Scrum and here is what I would strongly recommend you all - the Waterfall Manifesto. I assume the authors are serious when they describe this as - "Manifesto for Realistic Software Development"

Read on what author documented in waterfall principals (and they are so practical and true.....!) -
  • Changing requirements are a pain in the ass.....and make him pay dearly for just thinking about change.
  • Business people and developers ......They both have other important activities to carry to waste their precious time in meetings. Furthermore, they do not speak the same language.
  • Build projects around solid processes because you know that individuals are even more unreliable than software
  • Project reports and billable hours are the primary measure of progress.
  • Recognition of technical excellence and good design allows developers to think that they are free creative artists
  • Complexity - the art of maximizing the amount of time needed to understand your design and code - is essential to define your value as a developer ( and to protect your job).
  • At regular intervals, the team should meet to eat pizzas and drink beer. It helps developers to forget that they are working in a bloody software development project and confirms that the management really cares about people
 Reference and credits: www.waterfallmanifesto.org