Every agile team appears to break down the tasks involved in completing a sprint story item a little different Also, every team appears to have a different perspective on the Srum Definition of Done. My perspective aligns closely with one of my previous manager’s definition:
“A story is considered done, if it is shelvable, packageable and shippable. Basically at the toss of a hat, it can be deployed to production or made available to end customers with all associated artifacts including supporting documentation.”
This is the philosophy which I use as guideline when confronted with the task of splitting down sprint stories. And why so?
Let’s start by stating the assumption that we have a story with a well written, understood and itemized set of user, technical or deployment requirements. These requirements should drive both development, test and documentation. Or should they?
When a story is considered done, it should be possible to validate that each requirement was met, including existence of a shippable component to end customers, whoever they may be. Such that at the end of the sprint, the team collectively as a whole, including PM and additional stakeholders should be able to validate that each of the requirements listed in the story is appropriately captured in the resulting artifact.
There are various distinct developmental tasks involved in taking a marketable idea from concept to market. These tasks include:
- Design : captures some high level design activity including UX work for UI related stories.
- Development : everyone knows what this is all about. Yes, this is the task which captures all coding effort.
- QA: everyone also should know what this is about. Someone has to validate the output from the Development tasks to ensure it does meet user requirements specified in the story. An interesting point of contention I have run into involves the source document from which QA should author test cases. One school of thought says test cases should be driven from user requirements in the story and another says from the output of the design task. This alone is an interesting topic on its own.
- Deployment : this task captures work such as creating of chef scripts or other activities dedicated to ensuring code makes it from the build machine into our production servers. Some companies use DevOps engineers for this. Others get the same developers to do it all. Again another interesting topic on its own.
- Documentation: almost a task which never gets the time of day, especially if product is targeted to internal customers.
On one team, we had a hard and fast rule stating that EVERY story should be broken down into each of the aforementioned subtasks. However, as with a lot of things in life such hard and fast rules do not apply and often times completely break down, forcing the team into a “process oriented as opposed to goal oriented mindset” as one of my team members succinctly puts it. I see these tasks as mere guidelines. Completing some stories will require all of these subtasks while others will not and it is up to the Scrum master in consultation with the team to use wise judgement to make this decision.
Should these distinct activities be captured by individual JIRA subtasks? I personally think so. Individual subtasks allow distinct teams to start the work in parrallel, enabling early engagement by all respective teams, possibly allowing for faster delivery of the feature. Of course, the assumption here is we have distinct teams responsible for each facet of the development workflow. If we have a single developer responsible for orchestrating each of the aforementioned phases, it is no necessary to explicitly break down the story into such tasks even though it may be worth capturing the effort required during each stage of the workflow.
What do you other Scrum Masters do?