My secret weapons in the requirements world. Chapter one — Client.

My idea for this text is to share some techniques that I find useful on a daily basis while eliciting requirements. I decided to divide this story into two parts the moment I realised that I have a bit different approaches (and needs) when I talk with business stakeholders and when I cooperate with an agile dev team.

While discussing features with clients I usually focus on pains, gains, user’s behaviour and general business goals. However, when sharing all that with teammates I pay more attention to details, actual actions, their consequences and edge cases that have to be considered to meet our client’s expectations.

In the first part, I would like to present some techniques and tools that I value in cooperation with business representatives. Next time, I will share some hints on handing requirements over to programmers.

Questions

This one seems obvious, but sometimes I get the impression that some team members feel quite uncomfortable with asking lots of questions and — what is worse — repeating them or reminding about them frequently. But that is something you just need to get over with.

From my personal experience I can tell that the product owners and other business analysts appreciate this approach a lot. Once, a client told me that he admires my persistence. I took it as a great compliment, although I think that deep in his heart he wanted to say I am a real pain in the neck :) But that is what you have to deal with if you employ QA and BA in one person…

Sometimes, you can also get different answers if you ask the same question after a while — and that is the place where all magic happens. You identified some blind spots in the requirements and this is a perfect start to dig deeper.

When I prepare questions in a project that already has some part functioning (either on production or some test environment), I click through the system and try to think where will the new feature be placed and with which already existing elements it will interfere. This technique helps me to understand the system better, but also think off potential areas of interests.

Of course, asking simple questions like: why, what should happen if, where, when, who, etc. helps you understand what is really going on. But it has other advantages:

It generates completely new questions — helps understand better the tasks in scope.

It helps thinking you about the dependencies in the context of the entire system.

It helps to spot inconsistencies, both for you and the client representatives, as it makes you re-think what was stated in the acceptance criteria.

Sometimes asking questions creates new tasks and stories — that definitely makes splitting features and user stories easier.

Examples

These help me to precise requirements and find edge cases that need to be covered by the development team. It is easy — instead of asking for instance ‘What values are allowed in the input’, you can just use simple examples like:

Can I select x?

May I use y?

If I put X in the field, in result I should see Y?

If user clicks this button then he should be able to do something?

They are just yes/no answers. Definitely, if something is not right you will quickly get a ‘no’. A good idea is also to keep examples in tables, for example inputs and expected results.

I really recommend here ‘Specification by Example’ by Gojko Adzic. It states the obvious, but it can be a huge eye opener. It definitely was for me.

Example of tables — create them directly in JIRA issues

Flow diagrams

To be honest I use neither UML nor BPMN, I just create simple flows, so that they can be understood by me, designer, product owner (who are not technical creatures at all), but also be communicative to developers and quality assurance team.

I work with Gliffy for JIRA or draw.io (the latter is sometimes a problem — not each corporate partner has access to Gmail account at work).

And I use it for various subjects

to illustrate user’s journey,

to specify moments of decisions and alternative ways,

to summarise the changes in statuses,

to split a feature into several user stories,

to define what is missing in the feature or story

to handle story mapping.

To highlight that some details or stories are missing I create another block representing a user story but in red color, so that it could be easily distinguished from others. Sometimes there’s also need to mark pending and completed stories — for both I use separate colors and prepare a short color legend within the document.

Example of a story map — colors make it more readable

Design walkthrough

They always say it is easier to imagine the entire user journey when you have some kind of visual help. During design walkthrough I present designs and explain user flow using high fidelity screens, discuss the alternatives, share doubts. I noticed that we get far more comments when we show something than when we just discuss the behaviours.

Refinement meetings

Personally, I am not a huge fan of long meetings that require presence of the entire team, because it is hardly possible to keep everybody equally involved. I really enjoyed the moment when the team chose to work in more Kanban than Scrum way.

While introducing Kanban approach we decided to try out smaller meetings, scheduled when needed and attended by people actually involved in discussed issue. As the Kanban was a completely new thing both for the team and product owner (no previous practical experience on both sides) we scheduled a regular (twice a week) one-hour refinement meeting, so that we could follow the changes on our board.

It occurred to be a perfect time to share the screen and ask simple questions to ongoing features or discuss the flow while displaying designs. And get immediate feedback and decisions!

There is only one thing to remember — always write down an ultra short summary of what was decided. I do that in bullet points, directly in comments to each discussed JIRA task. That helps also developers to follow the arrangements.

Conclusion

Examples, flows and design walkthroughs are great for one reason mostly — they give our clients the occasion to complain and help me explore what they really need. Or confirm. Either way — it helps :)