Recently I’ve been involved in a conversation with a business analyser who is passionate of Agile but still need time to understand Agile values and principles better. The conversation is about how to get the business requirements.
At the moment, team is struggling to keep the stories to align with business values. And also because of the complexity of the system, team is also struggling to see the whole picture. So, in order to help team to shape the product backlog, this BA was keeping on asking the product owner to provide business requirements. And the product owner felt very difficult to do that because of uncertainties. When I’ve been involved, I asked BA why she required business requirements because everyone interpreted that request as specification document. She said that would help the team to see the whole picture. And then I asked her what kinds of artefacts she expected to get, she mentioned about some documents on company’s wiki site. Then the conversation became difficult when I tried to explain that the best way to communicate the detail requirements is to engage the team to have the face-to-face conversation with business stakeholders. And the documents can be used to capture knowledge/agreement we get from the conversation. She appreciated my point but still considered the document were mandatory before engaging the whole team in a conversation.
I felt a little bit frustrated about the conversation till a question came to my head. Then I asked her, “How will you get the requirements if the only tools on hands are just pens and paper and there were no computers, wiki, MS Word and etc.?” She said “I will write them down on paper”. Then I asked “How many pages do you expect to write for that document?” She said, “Just around 2 pages with some bullet items list about the requirements.” From then on, the conversation became more easier because she agreed that those bullet items were quite like user stories and we could create user stories and set up story mapping to help the team to see the big picture.
What I learnt?
First I should not assume the term of requirement document is about big upfront specification documents. Sometimes people will use some terms they are familiar with to explain the different things. I should verify it further about what its exact meaning is.
Second, it is quite usual that people will try to solve a problem with their previous experiences. Use some extreme questions will help them to think about alternative ways. For example, team might feel it is very difficult to get things done in a timebox iteration, questions like “How will we showcase to business in one-day iteration?” will help the team to think about what are the wastes in current process and how to eliminate all of them.