There is a growing trend within the Scrum community that believe when they are doing software development that it is actually product development. This is not the case. Software development is subset of work that is needed to be done to support product development.
In small organizations the deviation between software and product development might be small but the greater in magnitude an organization, generally gets the wider the difference gets. 
Scrum believes that you must have a cross-functional team that can get the Story/Task to “done”. Commonly this means that the team has the skills to be able to start the card with a meaningful conversation, develop it, test it, and deploy it. Often this results in Storywalls/Taskboards having headings like “Sprint Backlog”, “Analyse”, “Build”, “Test”, “Done”.
But what a lot of teams forget is that the software is only a smaller part of the organizational whole. Lets take a look other non-software components that are often involved in large scale product development:
- Legal
Sign-off of publicly exposed content to ensure that the organization is not opening itself up to liability; xtra-product only - Marketing & Sales
Promotions of campaigns related to the product; xtra-product only - Training
How users will use the product to perform their job; more commonly intra-product only - Communication/Change Management
How impacted stakeholders and users of the product will be informed of what is happening with the product development and rollout; more commonly intra-product only
xtra-product denotes a product that is sold to the public; intra-product denotes a product that is internally used within the organization
It is for this reason that I think Scrum’s label “Product Owner” is poorly named, or maybe more importantly has two few responsibilities associated with it. How many Product Owners have you met that have also taken on either the work listed above or the co-ordination of the above effort. They should. But if they did that and their standard Scrum duties they would be severely overburdened.
The cost of these extra activities are often just as large as the software development itself. Sometimes more, especially for COTS/Software as a Service implementations. Do you have Stories or Tasks in your Release Backlog for these activities? Why not? They have to be done and if are not aligned with the work that the software team are delivering then you are potentially opening yourself up to benefits realization risk. It’s all well and good to have the software on time, but if the change team haven’t been kept in the loop regarding when you plan on delivering minimal marketable features then they might be communicating that you are delivering them earlier than expected. Sometimes the success or failure of a product is never down to the software itself but how it was communicated and “sold to” someone; or how well they were trained in it.
How do you know that these other components are on track? Shouldn’t their work related to the product be fully visible and flow through from Sprint to Sprint?
If your product requires any of the above think about how you can incorporate them more into your environment and more importantly into your flow. Should the story/task be “done” if it hasn’t passed through these flow states. It doesn’t have to mean that every single story or task has to go to legal or through to training but it is a trigger – “will the training material need to be updated to reflect these changes?” If not, move it to done, otherwise wait until the necessary changes have been made before shifting it to done.
Agile Forest 