18 August 2015 Comments Off on Tips For Writing Agile Requirements PMO
Author: Andrea Reese Hurst
Coming from a waterfall development environment, I was used to polishing a requirements document to the nth degree before handing it off to development, but in an Agile environment, this put me behind schedule, and didn’t even make good user stories. Here are a few things I learned while working in Agile for a few years:
- Give the developer all the information they need to get a good start on the user story. The developer wants to sit down, plug away at a user story, and knock it out. You don’t have to be exhaustive, but give them enough to begin without contacting you first.
- Briefly summarize why you’re entering the ticket, whenever it’s not self-evident. When the dev knows your purpose, he or she may have a better solution. This is especially true of user stories that aren’t well-defined.
- Give the specifics up front if you have them. Don’t make the dev come back to you for stuff if you don’t have to.
- – Specify exact column names, field names, names of roles, and any other information the dev will need to finish it.
- – When the ticket involves complex permissions, or a variety of data sources, attach a spreadsheet specifying precisely what those are. It may seem like excessive detail this early, but it’s not.
- Include a picture of new features. Attach a mockup of any new features if you care at all how they look (which is 98% of the time if it’s for a business user).
- Break out compound requirements. If the requirement has a bunch of subrequirements, create an epic with links to subsidiary user stories rather than one huge story with bullet points. This
- – lets the dev take ownership of one subtask, mark it done, and move on, which is more Agile and – let’s face it – more rewarding than hacking away at one monstrous requirement for a month
- – lets multiple devs chip away at it
- – allows you to prioritize, comment on, add, or close out individual stories without affecting the other pieces
- – lets you and the project manager track issue progress more granularly.
- Make them aware of gaps. If you’re not sure of something but the requirements need to go out, add a comment specifying what information is missing (e.g., “Andrea needs to find out from Jeff whether we already have access to Table X,” or “Customer needs to finalize wording with Sales Department”) so the developer knows to come to you for an answer when he or she gets to that part.
- Don’t repeat yourself. Give them less to sift through. For example, if the mockup covers the layout, don’t describe the layout – just refer to the attached mockup by its file name.
- Ask for feedback on your first several requirements. When you’ve drafted your first batch of requirements, take them to the development lead and ask if these work, and whether you could make them more useful. Let them know you’re always open to feedback.
- Follow the item in the work tracking system. This helps you stay in the loop so you can report on the status of the ticket to your client, make sure development understood your requirement, and respond to comments by the devs or QA engineers.
Author: Andrea Reese Hurst
Tags:
