Should the work in a Sprint always be aligned to the Product?
I may have answered my own question, however, I thought I'd still ask to see if there are different views out there or if there are any gaps in my understanding.
What I was thinking was, can the Sprint accommodate work that may not result in an addition to the Product (Increment). This could for example be, training each other, working on process improvements etc. If the assumption is that, we need to learn first to begin developing something, and if that would need a week or two of training, then, would "Learn how to code in <specific language> and implement the necessary setup and configuration" be a valid Sprint Goal especially if we have already completed a few Sprints? If no, then what would you do during that period until you can Sprint again?
In a similar manner, if the Sprint Goal is to "Re-factor existing code to meet the current DoD", in my opinion, it is work that directly affects the product but it may not be a tangible addition that stakeholders can review, unless of course they understand the technical aspect of it.
Again, can process improvements or work other than the work related to the Product be considered part of the Product Backlog? i.e. should a Product Backlog Item always tie back to some functionality in the Product or can it be unrelated work as well?
It is just my opinion/preference of course, but I believe that sprint items should be customer facing as much as possible, and in all cases the Sprint Goal must be associated with something tangible and of value to the customer (internal or external).
I do not believe setting aside a sprint for learning, setup, and configuration is valid, as it reflects the anti-pattern of Sprint Zero to me. Surely, something of value, however small, can be delivered to the end user while this needed learning and configuration is taking place?
can process improvements or work other than the work related to the Product be considered part of the Product Backlog?
Who would own work of that nature and be in the best position to plan, order, and account for it?
Who would own work of that nature and be in the best position to plan, order, and account for it?
@Ian Mitchell, That accountability would likely fall on the Development Team, but there could be some instances where the Scrum Master may also be both responsible and accountable.