User Story Mapping

A lightening talk by Nils Christian Haugen (in Norwegian) on Smidig2008 (Norwegian Agile2008) was on User Story Mapping, as proposed by Jeff Patton. The user stories need a context, which shows how they generate value to the organization. So you have user roles, user activities and user tasks, which may be broken down into user stories.

Isn't this reinventing the Business Use Cases? Perhaps, perhaps not. I think it conveys the same idea, but I find the presentation an interesting layout of Use Case actors, more intuitive and easier to transfer to clients and developers alike. So I like it. Besides, they are devoid of the undeserved bad reputation of Use Cases as being written in stone.

What about epics? Aren't epics the same thing? Well, an epic is like a user story too big to be implemented in one iteration. But once you start implementing it, what then? You probably don't finish it all during one sprint, so it needs to remain, at the same time as parts of it appear as user stories. That creates kind of double messages, since they belong to different levels of description, and this leveling is not captured by the User Story technique. I think Use Case scenarios, Quantified Qualities à la Tom Gilb or User Story Map tasks capture this effect better. They also provide a framework for keeping the big picture in view and assuring that the user stories you pick support each other, and that together they make up a profitable user activity, or Business Scenario.

You may also ask whether this oveall, business level description belongs to the development team. Isn't that the Product Owner's table? I think experience shows that the Product Owner has a hard time setting up and maintaining this kind of plans on his own, and that it is extremely beneficial, if not mandatory, for the team to gain this overall level of understanding. So yes, I think it belongs to the team and serves well to support sprint and release planning as a complement to user stories.

Is software development an art?

In a recent blogg, MissUnderstodd asks the above question. I have noted that artists go to several years of education before. They learn a lot of techniques, aestetics, mechanisms and so on, so they know that to obtain a certain effect, they need to proceed in a certain way.

So do software developers. So yes, I think software development is comparable to the work of an artist. You know what you want to obtain, you know the rules for getting there and there is a lot of freedom for artistic work in between.

Naming the opposite of actual...

What if a formal parameter does not have the precondition != null? I have started to try out aBookingOrNull, like in

private void UpdateFrom(Booking aBbookingOrNull)

You may argue that this is just the complement of anActualBooking, so one of them is redundant. Instead, I could use either of the couples

• aBookingOrNull vs. aBooking (or just booking)
• aBooking (or just booking) vs. anActualBooking
  

I agree. But seeing aBooking (or just booking) on its own, it is not intuitive which of the couples I have settled on. So, for the time being, I prefer the couple where each of the two alternatives is explicit:

• aBookingOrNull vs. anActualBooking
  

Precondition Naming Pattern

As a dedicated fan of Design by Contract, I search to maximize the value of what I see as its two major contributions, communication and verification. The problem is that i.e. C# does not support executable comments. Information to a client programmer may be specified in a summary comment (will appear in a tooltip) and verified by a Debug.Assert, like this:

/// <summary>
/// Pre: booking != null
/// </summary>
private void ConnectTo(Booking booking)
{
    Debug.Assert(booking != null);
    ...

However, this introduces an undesired redundancy. So how to convey in particular method preconditions to a method caller without this reduncandy?

The technical precondition actualArgument != null is very common. Perhaps a naming pattern or naming convention might do, for instance anActualWhatever, the "actual" part stressing that the variable should actually refer to an object. I could get rid of the informatory comment, since the same information is conveyed through the name of the formal parameter:

private void ConnectTo(Booking anActualBooking)
{
    Debug.Assert(anActualBooking != null);
    ...

I think I will test this idea for a while.