Incremental Software Delivery

What i see occur quite often is that User Stories are to big, resulting in work that is not done at the end of the sprint.

Lets take a look at the story below:

As an office manager I would like to be able to lookup contacts quickly so that I can quickly find someone's contact details.

Acceptance criteria

• Given an Office Manager enters "como" When I press the search button Then he/she should see the contact details of everyone who's full name contains "como"

• Given an Office Manager enters"ce" When I press the search button Then he/she should see the contact details off everyone's title containing "ce"
• ...

Now if we think about this for a second, we could start to break down the tasks as follows:

• Create the database tables
• Create the data access layer
• Create the DTO's
• Create the UI
• Create the service layer

If we stop and think about this a second it does not really make sense in a incremental delivery mindset. If you reflect on this from a Form Follows Function Perspective, that the shape of an object should be based upon its purpose. This is a faulty breakup of the feature we are trying to build, since we are going to make the purpose - storing the data in a database and then transfer it to a screen - take precedence over the function, searching contact details.
It makes more sense tobreak up the screen in functional components as shown below:

Then we could break the feature up as follows:

• Display Search Results
• Enter Search Criteria
• Display status message "x out of Y contacts"

This will require developers to shift there mind from "Horizontal thinking" - thinking in terms of technical layers, to vertical thinking - what I often refer to as "Slicing the Cake". This enables you to incremental delivery of features and get earlier feedback.
The most important thing is the green grid displaying the search results. From a technical perspective this seems a bit weird, since we autmatically think that its not usable once we have hundreds of contacts. But this mindset is wrong, it is workable, whether its practical that is another thing.
If we would take this approach we could deliver the following screen to the Product Owner:

If he can get his hands on this he can allready take a look and maybe he could allready experience this bit of functionality and conclude he would like to add some fields to the grid like email and phone, that he did not think of immediately.
So an extra task is added to the story "Add email and phone fields to the grid"
In the meanwhile wile the product owner is allready playing around with the screen we can allready add the yellow part to the screen:

This will enable very short continuous feedback loops, moreover working like this will help you deliver functionality sprint after sprint.
This is what the end result could look like

As you see apparently there was no more time for the status message at the bottom of the screen and this task has been removed from the story another change from the initial version is also the "Search" button.
Find here an overview of what was implemented and what was removed:
As an office manager I would like to lookup contacts quickly so that I can quickly find someone's contact details.

1. Display search results: Done

1. Enter Search Criteria: Done

1. Display status message "x out y contacts": removed

1. Add phone and email fields to the grid: Done

1. Filter results grid when typing text: Done

1. Remove search button: Done

There is one caveat with this approach, business user tend to like alot to add stuff, but they really dislike removing stuff… But this is where the timebox principle kicks in, if for instance there would be no more time left than the 2 last tasks (tasks 5 and 6) than the Product Owner might still choose to accept the story as done and the Functionality could potentially be shipped.

Scrum.org PSM II Certification

I reached a major milestone and obtained my Professional Scrum Master Certification II last week. A put alot of effort in it and it paid of.

Determine Iteration Length

Something I come across quite often is that teams don't consciously determine the iteration length of their sprints. They usually take 2 weeks as some default length. This is not really the way to go… Lets see what criteria we can put forward to fine tune the iteration length.
Here are the 3 major factors to consider:

• Project Duration
• End-User commitment (how available are they to provide feedback and input)
• Maturity of the team

The shorter the project the shorter the sprints enabling to have more feedback cycles, minimizing the risk building the wrong thing. This however will require a significant amount of commitment of the stakeholders (weekly review meetings, availability to clarify and develop the product backlog with the Product Owner,...). Short sprints also have one big advantage they are more prone to fail… The reason why I see this as an advantage is that problems will surface more quickly, enabling your team to address them and thus further minimizing risk.
The second factor is also quite important: are there end-users available to provide feedback and are they easily accessible? One thing to keep in mind is that people are not used to the fact they will have to be available for a project throughout its duration. In the past they participate in workshops in the beginning of a project and in acceptance testing testing near the end (oh sweet memories :))
Finally you should consider how mature your team is. This means how experienced are they with agile practices such as Test Driven Development, Continuous integration, Test Automation, Collective Code Ownership (instead of finding out who broke the build, investigate and fix what broke the build), being cross technical (no specialist like the database guy, the UI guy, etc.). This however does not mean there is no room for specialists and that everybody has to be a generalist but everyone chips in where needed. A big obstacle are teams that divide work parallel with the layers instead of what i call "slicing the cake", this means implementing a feature from front to back, this will enable them to incremently deliver software.

For more information see: Agile Estimation and Planning from Mike Cohn

Visualize your workflow with Team Foundation Server

I created a custom report for Team Foundation Sever 2010 to visualize your workflow in order to identify bottlenecks

 

Identify bottle necks

This indicates a bottleneck in testing there is work stacking up for the QA department.

This report will tell you at a glance where to take action.

Inspect Flow

As you see in the picture above no clear “steps” for committed are noticeable in the above chart. The chart below shows a more healthy example.

You also notice that there is an inventory of untested items building up.