My secret weapons in the requirements world. Chapter two — Development team.

Last time , I went through some techniques I use to gather and manage requirements. Now, it is time to share some insights on cooperation with the technical types in regards to acceptance criteria and understanding business goals.

To be honest, I spend a lot of time writing acceptance criteria for user stories, but developers are not always keen on digging deep into them (too much text, attachments, related links, etc.).

I totally get them, but simplifying the user story is not always an option for me, usually for these reasons:

1. There is a bunch of people writing the acceptance criteria on client’s end. They use different styles, approaches, techniques, etc. I cannot always unify them for my team — it will take ages.

2. Sometimes clients are attached to the way acceptance criteria are specified and the wording really matters to them, but is not always easy-going with devs.

3. With clients we talk about users behaviours, goals and so on. But occasionally it is also good to have some things said in a simple way, like: add button, remove filter, redirect to, etc.

I work with a development team that consists of some frontend and backend devs, QAs, Dev-Ops and an UX/UI designer. That gives more than 10 people in a team. Each one of them focuses on what is most interesting for them or is their area of expertise, but in fact we have only one user story that has to satisfy all that needs.

Once, I asked the team to vote on some items that will help them deal with the acceptance criteria, to verify how to best present the requirements.

Except for splitting the stories to smaller and keeping translations in a separate file (we have lots of them as the project is conducted neither in our native language nor in English), the winner was:

Checklist

Actually, that surprised me. I supposed that flows or bullet points will be more popular. But I think it might be the power of feeling that actually something is done — because you can visually tick it off and see some progress at the end of the day.

Checklist summarises the acceptance criteria in a simple way. To create a checklist I create a page on Confluence that enables this option. I go through the requirements and try to form a kind of a simple to-do list. Then I link the list with the regular JIRA issue to keep all important details gathered in one place.

Simple checklist helps to monitor the progress.

Designs

Mostly helpful for frontend devs — looking at designs helps them to ask about edge cases and point out more technically complex part (this is usually more relevant for my future testing). Often combined with walkthroughs in show and tell manner. It is perfect if you have designs both for desktop and mobile/tablet devices, because they can differ a lot and lead to distinct observations and conclusions.

Walkthroughs

If a user story or a complex task has business needs defined, sometimes (usually, if the stuff seems to be more complicated that one could expect) I gather the team for a swift meeting where I firstly explain them in short the main business goals and the flow. Sometimes, we also go through the designs, if available. That gives the developers the general idea about the work that has to be completed before they have time to start detailed analysis.

Daily discussions

I try not to wear high heels to work, because usually I spend a lot of time on the move. Sometimes I make rounds from developer to developer discussing not really the tasks itself, but all the edge cases, problematic issues that came out after development have been started and no one predicted them while refining, analysing or planning.

I appreciate this time, as we can quickly discuss the issue, generate ideas, solve problems. I think that sometimes we get more creative that on any other ‘sticky-note’ meeting, because all participants do not feel the pressure of a Meeting. We just talk and focus on the important.

User flows

Even if not in UML or BPMN but in ‘human’, sometimes they seem to be more useful for devs, UX/UI designers than for your product owner. It helps to understand step by step user’s journey and make people aware of alternative scenarios.

What is perfect about this tool is that you actually do not have to know any complicated method of writing it down. mostly use only three elements — squares, arrows and decision blocks. You can just use draw.io add-on on Google Drive or Gliffy diagrams for JIRA to make some valuable flows.

User flow does not have to be complicated — just write down how you think user journey should progress.

Conclusion

I get that after the series my methods are no longer a secret :) Hope you find some inspiration in here. Thank you for reading.