Real World Example: Sizing Documentation Projects

When my documentation department first began estimating product documentation stories and tasks for an Agile development team, we used our own version of t-shirt sizing. Small projects were assigned a value of “1”, medium projects were assigned a value of “2”, and large projects were assigned a value of “3”. The values assigned to these t-shirt sizes helped us balance the workload across the writing team. A person with 6 small tasks and 1 large task had 9 units of work, which was the same amount of work as someone with 2 large tasks, 1 medium task, and 1 small task. As time went on, we added an extra-small and extra large size, with values of .5 and 3.5, respectively.

Initially, we managed the documentation in our own scrum team rather than including the work as documentation tasks within the development user stories. When it came time to get the documentation reviewed by the engineers, they did not have time to help us, as they were fully committed with development tasks for their sprints. In time, we were able to work with the development teams to explain that because the documentation is part of the product, we needed to find a way to incorporate documentation reviews as part of the development team’s process, as it had been before they switched to Agile.

We maintained our own scrum team to handle overall documentation efforts that did not require engineer involvement, like online help building and testing. Documentation to support product features was included as tasks within the related development user story. A user story for a new user interface (UI) screen could not be considered complete until the documentation for that screen was written and reviewed.