The agile methodology calls for “potentially shippable” product at the end of each sprint. How teams plan each sprint, write the user stories, and define the tasks lead to having a piece of product available to show customers for feedback at the end of each sprint. Note that I said a piece of product. The stories set for completion in a given sprint are the ones that need to be potentially shippable at the end of the sprint. I particularly like Kenny Rubin’s elaboration around the definition of potentially shippable: “Being potentially shippable does not mean the results will actually be delivered to customers. Shipping is a business decision; potentially shippable is a state of confidence.”
Potentially Shippable for Information Development
So what does this mean for Information Development (ID)? Information Developers are equal members of the team who must have their work complete in a user story to consider that story “done.” (See my article on The Whole Team Approach.) So the logical conclusion is that Information Development must also complete some amount of work to contribute to the team having potentially shippable product at the end of each sprint.
I’ve observed confusion around what “potentially shippable” means with regards to content. People often mistakenly assume the documentation must be ready to go at the end of every sprint, which leads to frustration since the entire documentation set cannot possibly be complete and ready to go every sprint. However, just like the coding and testing for only the user stories in the sprint should be complete, the documentation for only those user stories should be complete and shippable. This goal also means the user interface review for those user stories is complete and changes have been implemented. The concepts, procedures, and references necessary for that user story are done.
However, in an agile environment, the entire book and help system probably are not designated as complete and shippable until some ID-only user stories are complete in the last sprint (or even after sprints). Other documentation tasks, or ID-only user stories, probably are not done at the end of a given sprint.
ID-Driven User Stories and Tasks
ID-driven user stories and tasks happen during sprints. Note that these tasks are not related to work that Development and QE are doing. For that work, I recommend the documentation tasks be included and reviewed within the same user story as that Development and QE work (see Agile and Tech Comm: Adapting Your Review Cycle to Fit an Agile Model). These separate ID-driven user stories might include targeted documentation improvement tasks, usability testing stories and tasks, or user interface review tasks. And while they are driven by ID, they require time and effort from other functional areas, such as Development or QE. Therefore, when creating these user stories, ensure that the other team members add time for their parts in the review or implementation of your feedback for these.
It is common to have several ID-driven user stories at the beginning of a release cycle. Often when Development is doing research or working on infrastructure, ID team members have more time to make incremental improvements to documentation sets, run some usability tests, or work on instructional videos.
ID-Only User Stories and Tasks
In contrast, ID-only user stories and tasks often happen in later sprints or after development sprints conclude. These stories and tasks might include sending out the approval draft for review, incorporation of approval draft comments, production process tasks, and finalizing release notes. ID-only user stories do not require time or effort from any other functional areas, but are still pieces of work we must do for the release.
Another example of ID-only tasks is technical debt. If you have a backlog of documentation bugs and/or user comments, you likely address these independently of the work inside sprints that you’re doing in lockstep with Development and QE. You can do this particular type of ID-only task throughout the release cycle, depending on how much extra time you have in various sprints.
Conclusion
Understanding which ID tasks to include in user stories with Development and QE and which ID tasks to keep in separate user stories is important to your planning activities. If your team is using the whole team approach, you also need to allow for Development and QE’s planning activities, so they can allot time to the ID-driven user stories where they must contribute. Better planning leads to better execution. Better execution leads to more, higher-quality potentially shippable product at the end of each sprint for your customers.
Useful Links
- Agile Glossary Definitions, Innolution website. http://www.innolution.com/resources/glossary
- Definition of Done: A Reference, Scrum Alliance website. https://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference
