Open Space Notes: Is it always about having a potentially shippable increment?
Is it always about having a potentially shippable increment? If not, what is it?
In games development we find that the number of iterations is one of the most critical factor in getting to a high quality product. In practice, this means getting to working software as quickly as possible and then iteratively gathering feedback and rapidly iterating to ever better versions. This means we end up with stories in varying states of ‘doneness’ at the end of each sprint, none of them likely to be potentially shippable until very late in the whole project when we are close to shipping a boxed product.
To help cope with this, some teams in our organisation (Electronic Arts) have adopted a framework to both specify and then track these iterations. One example has come to be known as “SWTAG”, where each letter is shorthand for a specific level of ‘done’. In this case:
S = Sufficient for feedback. Generally the first time something can be seen in software, however incomplete.
W= Working. The functionality is broadly in place but art work (e.g. graphical quality, UI) may be very low fidelity or placeholder.
T= Testable (by kids in our case). The software is sufficiently done to put it in front of people that have not seen it before and for them to be able to use it with minimal intervention.
A= Alpha. Potentially shippable, likely needing some polish and bug fixing.
G= Great. Shippable and likely to receive a great review score.
Each story card is tagged with one of these letters at the start of a sprint to define the expectations of how done it will be by the end.
Summary of Discussion
There was general agreement that for some teams, getting to potentially shippable within a sprint is not always feasible (although for many teams, it is).
There is a distinction we could draw between complete and shippable.
A key point to emerge was that we can define shippable “to whom” at varying levels. In this sense, the SWTAG definitions could be rewritten as follow:
S-Shippable to peers or the designer on the team
W- Shippable to the product owner on the team
T – Shippable to focus testers and the business owner
A – Shippable to anyone in the company to review, possibly even externally
G – Shippable to the consumer
One thing that can ease things is to get better at helping product owners define small increments of functionality and get then out of the ‘all or nothing’ mentality.
We could also consider the iterative approach to be a versioning approach, e.g. version 1, 1.1., 1.2, 2 etc as we build towards a production release. It may only be shippable at version 2 even though previous versions are valuable to the product owner to assess progress and provide valuable feedback about direction of the work.
We should also remember the distinction between done for the sprint vs. done for the release, which may require additional effort (integration, testing, deployment) and will generate additional backlog items.
Some people suggested that alternative words might help, e.g. “delivered” rather than “shippable”
There are overlaps in this discussion to the Open Space topic on “What Done Looks Like.” It is certainly critical that whatever done means, it is defined at the start of the sprint and is clear and agreed among all parties.
Stories can be broken down into smaller stories – for example these might correspond to SWTAG iterations (with a story for each), other levels of done or small elements of the functionality coupled with an integration story.
Another team is using a hierarchy of usecase-feature-story to define the work but always retaining the overall usecase as the final testable functionality. It would be the same is a story/epic is broken into smaller stories – the high level story may need to be retained to ensure we can test this in a release at some point as well as all the sub (or child) stories. The high level (parent) story may also have story points still associated with it to allow for integration, testing and release work.
Suspicion is that in defining iterations in a SWTAG way, the effort for each iteration increases not decreases. E.g.
Iteration 1 = 10%, Iteration 2 = 20%, Iteration 3 = 30%, Iteration 4= 40% of total effort. This may help explain why we often underestimate as we may assume that the effort decreases hence if we have something in software, it will be a small job to finish it yet in reality the finishing (to rbust, high-quality production standards (is what takes the time.
We could also consider the steps along the way (e.g. iterations) as delivering value. Ideally this is business value but could also be learning, or defined progression to a goal.
Overall the group felt that we should not be worried about bending or modifying Scrum to suit the reality of our situation and to ensure that we deliver what the business requires. If that means iterations to done, so be it. If it means that the definition of shippable is qualified by "to whom" then also that is OK.