I have worked with many individuals, teams, and organizations in the use of Scrum. During that time, I have found that 2 parts of Scrum continually overlooked in implementation. Since Scrum is already a minimal framework, just enough to keep a team out of chaos, when a piece of Scrum is left out problems are bound to occur. The 2 most common parts that I see left out are:

• Product Vision
• Potentially Shippable Product Increment

Product Vision

There are times that I work with a project team and ask what they are going to be developing. If the answer involves a list of requirements and the team has difficulty in describing how what they develop will deliver value then I know there is a missing product vision. This happens more often than you might think. If you want to check if your project team has a common understanding of the vision, do the following with the entire team:

Each person on the team please write down what the software we are delivering will do for its users in 1 paragraph. After we have all written a paragraph, each person on the team shares their understanding with the rest of the team.

If while going around to each team member there is another person on the team who disagrees with the part or all of someone else’s understanding, then your team might not have a product vision. At the very least, the product vision has not been communicated well to the entire project team.

A simple way to generate a product vision is to use the elevator statement template from Geoffrey Moore’s book “Crossing the Chasm”. Here is how it goes:

FOR (customer) WHO (statement of need) THE (product name) IS A (type of product) THAT (has this compelling reason to buy/use). UNLIKE (competitive products) OUR PRODUCT (is differentiated in these ways).

Filling out this elevator statement template with the information in parenthesis with the entire product team will help them get a common understanding of the product’s vision. If the product does not have a coherent vision or through the filling out of this template the value of the product seems to be missing, then this could also show that the project team should not be working on the product. If that is the case then the team could start working on something that will provide more value.

Potentially Shippable Product Increment

Many teams decide not to create potentially shippable software at the end of some sprints. It is difficult for the project team to work in a manner that would produce a potentially shippable product increment. This could be because:

• Roles on the team are too specialized
• Lack of motivation to work together
• Product Backlog items that can be completed by only one person on team
• Doing “Scrumerfall” or “FrAgile” (meaning design/code/test phases within a sprint cycle)
• etc..

Create a Definition of Done with the whole project team is a first step to working towards potentially shippable software each sprint. The Definition of Done involves all team members agreeing upon what they are able to deliver to product consistent internal quality in the software each sprint. The team will include members with backgrounds in programming, testing, analysis, design, and other disciplines within the software development field. The discussion that occurs in developing the Definition of Done will enlighten each member of the team and provide a way for them to keep on top of their internal quality as feature are being delivered iteratively.

In Summary

I hope that people read this and are able to identify whether they are doing these 2 essential parts of Scrum effectively. If a team does not know where they are headed, day-to-day decisions with an iterative and incremental approach such as Scrum will evolve into a messy implementation with no coherent focus for the users of the software. Getting a product vision and communicating it effective throughout the project team and even to stakeholders can help provide guidance along the way. If the team is unable to deliver a potentially shippable product increment after each sprint then the product will always have leftover work to do in order to get a release out to the users. This work will be to stabilize and pull functionality together in a coherent manner which is usually unpredictable leading to decreased quality and missed dates on delivery. Working on a Definition of Done as a first step towards understanding what is meant by potentially shippable product increment each sprint will begin the process of getting to software that is of releasable quality from the technology even though the Product Owner wants to go another sprint or more before actually releasing it to the users. Also, looking at the Extreme Programming (XP) technical practices to help create software in an incremental manner can help put the Definition of Done into action more effectively in some circumstances. Happy Scrum-ing!