Do requirements in your project change late in the game? Probably, you asked questions late in the game or someone in your team made early assumptions and did not validate them with business users. Or you resisted changes in some way or the other. One way to resist change is to avoid collaboration with business users assuming that collaboration can induce changes. The truth is that you resist change to requirements, changes persists!“In life, what you resist, persists”, says Werner Erhard. How true!
In Requirement Engineering there are several weak links! Are you a developer, or a tester, or a team member who receives requirements specifications or user stories from business analysts or product owner? Do you expect business analysts or product owners to provide you with clear requirements detailed enough for you to code, test and deliver software? Think practical! You have a role to play!
You have to understand what business analysts or product owners provide you. You have to ask questions as early as you can. You have to think in terms of test scenarios and test data. You have to validate your thoughts and assumptions whenever you are in doubt. You have to think about related user stories and conflicting requirements. Instead of doing all these, if you are going to remain a passive consumer of the inputs received from business analysts or product owners, I am sure you are seeding issues. Late in the game, when you ask questions, you will receive answers. These answers will manifest as ‘last minute changes in requirements’. Do you want to think, collaborate and elicit requirements early? Or do you want to blame on changing requirements?
Think! You have a role to play! You have to ask context-free questions as well as context-specific questions. You can’t be a passive consumer of requirements who wakes up late in the game plagued with changing requirements! When you become an active participant and exhibit collaborative spirit you will embarace change comfortably and ensure quality before design!
Scrum teams do backlog grooming. Is it working for you? What else do you do to elicit and refine requirements?
By the way, do you know how tea bag was invented? It happened by accident. Yes. It was an accidental innovation! Can we let our projects mature by accident? - read this blog for more information. I have linked my recent podcast on distributed agile to this blog post.
2 comments:
Great post. As you noted, asking questions as early as possible is key. Assuming an answer is almost guaranteed to produce re-work.
For changes (as opposed to clarifications), we work with the customer to identify impacts and value, then allow the customer to decide. Making them a partner in the success of the project pays dividends.
Thanks Gene! Interesting comments!
Working with the customer to identify impacts and value and collaborating with the customer in prioritizing requirements is a result-oriented practice. I have shared similar thoughts in my blog post 'Requirement Specification: The Weak Links' at http://se-thoughtograph.blogspot.in/2012/04/requirements-specification-weak-links.html - this post has a link to Tom Gilb's white paper on this topic!
Post a Comment