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.”

We had an exciting week at Artinsoft. We are very close to an alpha state of our product named Aggiorno. What Aggiorno is about? Well,l I can’t tell you yet until release. But I can tell you I don’t know any other product claiming to do the same thing.

After several Sprints, we are ready to follow all the sacred guidelines for conducting Usability Tests. How do we know about those? Artinsoft foresaw this necessity and I was sent to the Usability Week 2007, Washington D.C. on April 22 through 27.

Roughly, I am leading the following steps

• Recruiting people based on a Screening definition.
• Scheduling the usability tests.
• Executing the usability tests
• Analyzing the usability tests

Recruiting people based on a Screening definition

To make a long story short, we found a way to form partnerships with high quality companies whose employees can be benefited with product. They found users (that fit our Aggiorno User Profile) able to willingly participate in our usability tests.

I am especially grateful to those companies for helping us to make a very usable product. I would let you know who they are very soon.

In this matter I just want to point out how important was to recruit just five users for this product stage. The reason is clearly explained in the following article Why You Only Need to Test With 5 Users of Jakob Nielsen. Nielsen was one of the speakers at Usability Week. I had the chance to talk with him after the training in order to discussing how to fit agile processes with Usability Studies.

Next steps

We setup our Usability Lab to run the tests at after work hours. I improve considerably my facilitator skills with each usability test, I love it!! Currently, we are evaluating the Morae software of Techsmith and in a future post I will let you know my opinion about it.

In this picture you can see me facilitating the test and explaining the setting of the usability lab to one of our users.

Keep tuned!