David Alfaro: Scrum Costa Rica

The immediate purpose of software development is precisely that: SOFTWARE. Our ultimate goal is delivering software. The prize (whatever it could be) will depend on software delivery success. You will feel in the right path as long you now what your customer wants and how you can satisfy him.

The more quality our delivered software has, the more fulfillment our purpose reaches. All the software we produced should be supposed to be used. We make it for our customers. Our customers are represented by the Product Owner, who is able to realize and prioritize the features (User Stories) that the end customer wants.

The software or product is made out of features. Sometimes the team forgets about the business value that every single task should have. Certainly, the explicitly stated business value is in the User Story. However, when it comes to take that User Story and disaggregating it into tasks, all the team is responsible for remembering how every single technical-level task is going to build the committed User Story. Every single task should be able to make (directly or indirectly) our Product Owner happy.

Each Sprint has a compass: The “sprint backlog” out of the Product Backlog. Every release has a compass: the Product Backlog out of the Roadmap. As you can see, each user story of the sprint is a glimpse of what our customer or Product Owner wants.

Iteration Zero
What about “Iteration Zero” ? By “Iteration or Sprint Zero” I mean that period of time when the team doesn’t feel able to deliver a “potentially shippable increment”. Before that, team needs to make some setup and “architectural” decisions.

In that special Sprint, many teams had found useful to make User Stories whose Product Owner is “The Team”. Even without the normal nature of the Product Owner and without the normal nature of User Stories, the Team needs to be focused. In those circumstances, the Acceptance Criteria are still extremely important as well as the Iteration Zero Review meeting. If not, you will find your team upset and lost. Without a clear goal (set by User Stories with Acceptance Criteria) it is highly probable get distracted and get developers implementing unnecessary stuff.

Once you start to deliver business value, that is, product features, you will find your team uplifted when they can see a satisfied Product Owner reviewing the completed User Stories of the Sprint. That experience is extraordinarily motivational and depends on the quality and completeness of what is delivered.

Before leaving I want to give you this quote from Mike Cohn’s book Stories Applied: For Agile Software Development

“A team is not allowed to deliver half of a feature. Similarly, a team is not allowed to deliver the full feature but at half the quality. By the end of each iteration the team is responsible for delivering working, tested code that can immediately be put to use.”