David Alfaro: Scrum Costa Rica

Finally I am back!! I apologize for my temporal aloofness!!
I was reading interesting postings at ScrumDevelopment group about Taskboard and how the progress is visualized so I want to share some ideas from our particular experience.

A very engaging aspect of Scrum (and Agile in general) is to find innovative ways for solving problems found in the Retrospective meetings. By the way, the Retrospectives are are rich well of requests and improvement opportunities. By pandering to those requests (and inspecting at the solutions) you will get a tailored improvement to the process.

How do we at Artinsoft do for keeping track of our Sprint progress using the Task Board? Let me explaining it to you by telling you the story.

We have acknowledged that the following phases are needed in order to set a done criteria for the User Stories we committed:

• Design: Meetings to discusses architectural issues,
• Development: Coding
• Application Quality Improvement: Pair Programming and/or Code Review. We prefer Pair Programming.
• Testing: Quality Assurance in the way of Developer or Integration Tests
• Usability Tests

Additionally, a sixth kind of tasks emerged: Environment, as a mean to say that it is a task that encompasses all the environment setup (technology setup) to accomplish the User Story.

Well, in one Retrospective long time ago we pointed out that some User Stories were lacking of enough quality. Why? …. Got it! one or more aforementioned phases were being skipped when planning and implementing features. Why? We EASILY forget to get sure we get them while planning and even implementing. At the second level of “Why?” we realized we needed something catchy to remember those phases and to avoid the constant tendency of realizing them when the deadline is looming, or even worse: never!

We devised a solution: Use a specific color for each kind of task when doing the Sprint Planning and do a Color Distribution Assessment constantly: Do we have enough of all colors for all User Stories? If not, is there a unanimous and intentional awareness of it?

Our Taskboard looks like this:

We always have a good supply of sticky notes next to the TaskBoard, one color stack per phase or kind.

Along the Sticky notes we also have a supply of red round labels. Why so?

In the diagram, I pictured an hypothetical second day of the Sprint, in the Stand Up. The team member David (hence the “D” in the sticky note) delayed more than the recommended (and estimated) one day for that pink task (Usability) he committed to finished. He sticks a red round label to the task and in that way the Task Board is irradiating to the whole team that we are behind of the Sprint schedule.

Again, this has worked for us and fits to our specific circumstances. What do you think about it? Feel free to give me your opinions, all your comments are needed and welcomed!!

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