As teams strive to move to a mature agile process, technical writers must adapt as effectively as the development personnel. This new agile process demands that knowledge dealing with software or product releases is only sparingly documented up front, making the technical writer's job of gathering information much more dependent on talking with people over reading requirements.
In agile development, a bloated backlog results from teams accumulating huge lists of requirements, usually in the form of user stories. Retaining every possible story for building the product weighs down the backlog while squeezing (or obscuring) the highest-value stories. The best way to help minimize this risk is to optimize the time spent defining and refining the product priorities.
Writing independent user stories seems simple, but it is actually difficult to do well. There are often parts of some stories that are dependent on other stories' functionalities, so it's not easy to keep them separated. Kris Hatcher relates how his team wrote and scored stories to keep them independent but still meeting acceptance criteria.
You can use analytical methods to assign business value to a user story, of course, but another way is simple estimation. Allan Kelly describes an estimation exercise that combines the Scrum tool of planning poker with a TV show format to add some fun. You end up with enlightening conversation and revealed requirements.
Business stakeholders and DevOps teams both have to take an active approach to app development, but neither faction should have to change practices and processes in order to get their needs across. Investing the time to establish communication between these teams will drive delivery of the applications customers demand.
Nonfunctional requirements describe aspects of the system that do not map onto a single piece of functionality. Essentially, they're constraints you need to operate within. Allan Kelly details how running performance tests regularly can be the key to nonfunctional requirements, as well as how much value these constraints produce.
One of the benefits of agile is how it helps specify requirements. Instead of trying to predict the future with your requests, you can wait an iteration and see if more criteria are needed. This article gets into how executable specifications, specification by example, and test automation can help further improve your requirements management.
Acceptance criteria can be helpful in expanding on user stories in order to capture requirements for agile projects. However, acceptance criteria should not be a route back to long, detailed documents, and they are not a substitute for a conversation. This article tells you how and when acceptance criteria should be written and employed.
If you really want to get the benefit of Scrum, you have to make the mind shift to product ownership, not project management or project ownership. The product owner role is often thought of as being a requirements specifier, when in fact a good product owner is a value maximizer, and a great product owner is a product maximizer.
Some teams only work with stories, but it can be difficult for a team new to agile to write stories that are easy to understand and provide value every time. An alternative is to add epics and tasks. Understanding the differences between each level and knowing what size story to use for each situation will improve the accuracy of your sprint planning.