How to deal with business requirement documents?

It is interesting that organizations send few folks for Agile trainings such as ScrumMaster but don't have any plans to become Agile. For some managers, it is just about meeting their training goals. Here is a typical scenario where business just handed over a big business requirement document (BRD) document with lots of requirement to this theoretically trained ScrumMaster. A common reaction from the ScrumMaster new to the agile world is not positive. He thinks, how can he change BRD focused environment to an Agile environment? It's challenging and frustrating. Should he give up?


True that environment is challenging but remember "winners don't quit". They use common sense. I also call it ScrumSense. Let's review how you can give a positive twist to this scenario using my rules of thumb.
  1. Lucky you, you just got a list of product backlog. Many teams doesn't even have such a backlog. Be happy and do a very high level estimation of the backlog. Normally, you don't need to estimate the entire product backlog in the Agile process but your team is not Agile yet, hence, you need to estimate backlog anyways. Trick is to first do a very high level estimate to save efforts.
  2. High level estimates may suggest that release will need few months to complete - let's say estimate is 9 months. This is another good news because you have an opportunity to impress your team by demonstrating agile value proposition. Ask business if they need all functionality after 9 months OR if they will be happier if you deliver them entire functionality in 3 releases in 3 months iterations. I will be surprised if business rejects this offer of getting value incrementally.
  3. Next step is to ask business to provide a stack-ranked list of functionality so that you can pick up top priority items for the first mini-release. This list becomes your release backlog and remaining stack-ranked functionality becomes product backlog. If your engineering team is capable then you can do monthly sprints and do demo to the stakeholders after every sprint. In any case, I am sure that you will agree that planning for 3 months is more realistic then planning for 9 months.
  4. Now you are in the last week of the mini-release assuming you are almost ready to do first mini-release. Ask your business if you can take highest priority items from the remaining product backlog for the mini-release #2. What do you think will be the answer? Try and experience it. I tried it many times and I consistently get the same message:
"Business priorities have been changed and we have a different list of functionality to implement. We like this iterative process."
As a leader, take responsibility of demonstrating to your organization that change is the only constant. Let's embrace it and think iteratively. This could be a good beginning for your agile journey. Good Luck!

Mr. Agile explaining to Mike how to help business to be agile.


References:

No comments:

Post a Comment