David Alfaro: Scrum Costa Rica

The Product Owner role is highly important within the Scrum Process. He is in charge in getting sure the team is delivering business value.

Building a Product Roadmap
Building a Product Roadmap is an art. I had had the chance to talk with Luke Hohmann, founder and CEO of enthiosys, about all forces you need to take into account when you set out on defining your product roadmap. Surely, you can find an excellent and comprehensive explanation of Luke’s insights in his amazing book “Beyond Software Architecture: Creating and Sustaining Winning Solutions“. Luke’s advice and guidance have been instrumental for me to successfully push towards a realistic planning state in my projects at Artinsoft.

Up to now, I just tell you how important is to establish a clear distinction between the system’s architecture and the business perspective of that. Combining the business value features, market forces, technological forces, and events (among other things that I will blog later) you are able to build a roadmap.

The roadmap will provide you deadlines and features in order to build an Agile Release Planning. The ScrumMaster training given by Stacia Broderick is a wonderful source of tools for an effective release planning.

Along with the team, the Product Owner is ready to organize the priorized features by Sprints . That is, in earlier sprints the team will deliver the highest business value!!

Product Owner’s Fairy Tale
Ideally, before starting development, the Product Owner has a clear idea of what is needed for the product to be profitable. He has clear idea of all the market behavior and since he is supported by an experienced marketing team, building a Roadmap is just one more step forward.

In this ideal world, he just sit down and write all the User Stories needed to accomplish that wonderful profitable product. With a brightly bunch of User Stories, he now can sort them by business value: from the highest to the lowest. Let’s make an Agile Release Planning and voila! just let the Scrum team bring potentially shippable increments.

Wake up!
The most powerful weapon of Scrum for software delivering is Adaptation in an uncertain environment. In most cases of the real world, the Product Owner just has some idea of what is needed to have a profitable product. Even more difficult: maybe the team doesn’t have a velocity yet because they have never worked together and don’t have a deep understanding of the possible platform. Does it mean we don’t need a Roadmap and Release Planning? Well, this when we need them the most!

I’s alive!
Roadmap and Release Planning are Adaptive! I don’t want to touch metaphysical areas, but in order for something to be adaptive, that something needs to be animated, for me: alive! The Product Owner needs something to start with. At least he would have a fuzzy idea of the product. At the beginning the product features, technology and marking architectures are vague. THAT’S FINE! Let’s do our best in defining the Roadmap and the Release Planning.

Product Owner, remember: be responsive!
For the product perspective, each Sprint will give you high quality software to play with and that will give a magnifying glass to discern what do you want. You will sharp your vision with every Sprint. Every Sprint will give the chance to be more concrete in the Roadmap and Release Planning. Don’t miss an opportunity to update them. Every time you update, do all the meritorious market research, try to be more concrete and definitive in deadlines. Deadlines are important as we don’t have infinite resources to be vague all the time.
For the team perspective, each Sprint will give you a solid idea of what is your velocity based on what was done in earlier Sprints. Team velocity is vital parameter to wisely update in the Release Planning.

That’s all folks so far. Keep on tuned!

“Inertia is a non-quantifiable property of matter by which it remains at rest or in uniform motion in the same straight line unless acted upon by some external force.”

“Sprints are short running races in athletics. They are roughly classified as events in which top runners will not have to “pace themselves”, but can run as fast as possible for the entire distance.”

Let’s mix Physics, Athletics and Software Development: Scrum’s Sprints are meant to have an increment in the team’s metabolism so we can run as fast as possible in a motion near to uniform. Once we start to “run as fast as possible” , we feel the inertia that help us to complete the race. A race against time.

So, let me point out two specific features related to a Sprint:

• In athletics, I normally see that the longer the sprint’s distance is, the lower the racer’s velocity is.
• In physics, gravity acts as the external force that finally stops the uniform motion.

Sprint Duration and Gravity
For a good use of your team’s inertia, you will find out that a two week sprint is the best, look a this post of Tobias Mayer about it. In a three week sprint (or longer), you will see your team not running as fast as possible through all the sprint stretches. Why so? Because external forces start creeping around you. Examples of those forces are: errands and meetings that are not related to your project. The false sensation of “we still have plenty of time to finish this task” is like that gravity that slows you down.

Uncertainty is something to expect. However, in longer sprints, uncertainty become a strong hindering force. In shorter Sprints, uncertainty becomes tamable and even beneficial to get “the agile edge“.

The Sprint Review is as rewarding as winning a race could be. Why do you have those rewards not so often?

Two Weeks Sprints are highly recommended. One week sprints are specially great in those cases when product definition is in its very early stages. In that way, the Product Owner can shape better what he wants by seeing highly frequent increments of the product.

If iterations are so often, you need to keep Planning, Preview and Retrospective meetings in a proportional timeboxing. You can’t have a eight hour Planning Meeting for a One Week sprint.  These meetings are vital and also have to be effective.

Doing Scrum is not running like a mad. It is running effectively little and smart races that are part of a big circuit or championship. That championship is explaining by the Roadmap, which I will post my comments about it very soon.

Keep on tuned!