Documentation stories: managing Doneness thru JIRA workflow v. using tasks for Create/Review/Publish?
For my first question to this community, I've got a simplish question that we keep noodling with: how to best manage the workflow of documentation stories in JIRA?
Basic use case: A basic doc tasks goes into the sprint. It will involve creation/iteration for review & edits/then publishing.
The doc writer typically Resolves the JIRA when he's created the doc and sent it for review. However, after review the doc inevitably needs to re-work, and hence is back in the Open state. Re-opening the JIRA as a matter of course doesn't seem right.
So, one could fairly point out that maybe we aren't using the JIRA workflow properly.
On the other hand, we think that maybe we should break the story into three tasks to track the stages of work. Seems logical, but requires a little more overhead.
What practices have people found to useful in this situation?
Thx.
--Geo
Why aren't the creator and the reviewer collaborating on work in progress in the first place?
It sounds like you've configured things so the work follows skill silos, instead of having people collaborate on the work.
Hi Ian -
I hear what you're saying, which is that the Review/Publishing work is simply part of task execution. Which essentially means we need to clarify our JIRA workflow.
So this still raises the question, how can be get ready transparency into the stage of work the doc is in? Any thoughts? Would setting up tasks those stages be wrong or superfluous? Perhaps because we're not on a development team per se we're not faced with this sort of bookkeeping that others might experience vis. development and testing for a given deliverable.
You can plan and replan tasks, as needed, to complete a user story which is in progress. Work then isn't sent back. Rather, new tasks are identified. These can include reviewing or anything else needed to satisfy acceptance criteria or the Definition of Done.
Hi Ian -
Thanks for your prompt responses. I'd like to get better acquainted with how the approach you describe works. Are there any online resources you might be able to point me to?
Thx.
--Geo
"Sprint Backlogs in Practice" may help:
https://dzone.com/articles/sprint-backlogs-practice