I am curenlty working in an agile environment as a manual tester and having a hard time in explaining the user stories to the developers so they can implement it properly. Althought the user stories are self explained but still they come to me and ask many questions. I don't have enough time to explain and then test it.
Previously in waterfall we used to make a requirement doc. and then get it approved from client, only after that we start working on them but i am not sure about agile as documents are not made in this process. What porcess should we follow here? I was thinking of a data flow diagram or something else? What can be done to improve it?
I think Agile approach is also compatible with creating some documentation. Even if customer does not expect you to create it at the moment, why not document at least some basic concepts for your inner usage and keep this information in some local space shared with your team. Sadly, people tend to forget what has been discussed, especially when being overloaded - unless it has been written down.
Visual scheme is actually a great start. It is usually much quicker to draw a simple model of your product than describe it in a text form. You can start with most basic blocks: e.g. data input -> processing -> data output. Then go deeper into details where it is needed. You can create several models displaying different approaches:
Functional scheme - showing how the product works from developer point of view (it relates to the white box testing as you know the inner structure in this case);
Business scheme - how it looks from a customer side; etc.
Besides, having some inner documentation would be helpful when a new person joins your team. It will make onboarding much faster.
Well, if we were to assume the user stories are truly self-explained to anyone and NOT only you, then you must find out why your developers still don't "get it."
I suggest you proceed as follows:
Find a way to get together a multi-disciplinary team, e.g. Marketing, R&D/Engineering, Production, Finance, Supply chain/Operations and Quality so ALL of you could develop TOGETHER a set of measurable, non-ambiguous and non-conflicting User Requirement Specifications (URSs) for your new product. Your project's senior management sponsor is the right person to empower you to accomplish the above task. Next, work-off from that document as if it were your New Product's Bible!!!
I've only done Agile development at two different companies, so I'm not going to claim to be an expert.
That being said, something seems to be done very differently here than at the places I've done agile.
Why are the developers asking a tester what the stories mean? Who is authoring these user stories? At places I have worked it would be the product owner or development leads. In any case, during story grooming and sprint planning meetings (or hopefully before) the developers should be asking the user story author(s) for any clarification that is needed.
Earlier responses by Michael and Costas are also right on in saying that the stories don't have to be the only documentation for a project. It's quite possible to have an Intranet site with higher level documentation about the project, which could include overall application workflow (assuming it's an application) and also UI mockups showing what's wanted. The stories can then link to appropriate pages on the Intranet site.
-Eric
StickyMinds is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.
