Story about User Stories

It’s amazing how people somehow manage to figure out ways to abuse systems that they once so passionately fought to bring in. I recently came across a user story card which had the whole sequence diagram scribbled on it in an extremely small fonts. Interesting work-around, isn’t it? For those who have not seen one, a user story card is typically a 3×5 index card used by many organizations to represent a user story.  The small size has been selected for a reason. The idea behind having a 3×5 index card is to constraint the user story to short and simple.

But user story card is just a part of the story. Let us try look at the whole story itself. Please allow me to tell you the story of user stories.

A user story describes desired functionality from the business perspective; it is the user’s story. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used. I completely agree with Mike Cohn’s favourite Template for writing user story which are short and simple,

As a [user role]

I want [functionality]

So that [reason]

 A user story is comprised of:

1. Card – the written description of the story, serves as and identification, reminder, and also helps in planning.

2. Conversation – this is the meat of the story; the dialogue that is carried out with the users; recorded notes; mockups; documents exchanged.

3. Confirmation – the acceptance test criteria that the user will utilize to confirm that the story is completed.

A very good guideline for writing good user stories is the INVEST model

Independent – One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.

Negotiable – A user story is negotiable. The “Card” of the story is just a short description of the story which do not include details. The details are worked out during the “Conversation” phase. A “Card” with too much detail on it actually limits conversation with the customer.

Valuable – Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. Once a customer realizes that a user story is not a contract and is negotiable, they will be much more comfortable writing stories.

Estimable – The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).

Small – A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is more than that in effort can have more errors associated with scoping and estimation.

Testable – A story needs to be testable for the “Confirmation” to take place. Remember, we do not develop what we cannot test. If you can’t test it then you will never know when you are done. An example of non-testable story: “software should be easy to use”.

So the moral of the story is this. User Stories being the cornerstones for Agile development, deserve their fair share of time, effort and most importantly prudence to be “invested” in them in order to lay a strong foundation for project.

Advertisements

IOC Containers Demystified

When I first came across this big buzz called IOC Containers, I found it very close to a factory class in its purpose and philosophy. As I dig deeper and deeper into the concept, I find myself more and more convinced that an IOC Container is nothing more than a Fancy Factory.

Amid all the mumbo-jumbo around it, these IOC Containers actually quite simple at their hearts. IOC Containers are essentially a tool for Dependency Injection. The whole idea being able to invert the flow of program control in a manner that maximum amount loose coupling can be achieved. Hence the name IOC (Inversion Of Control) Container.

Sounds vague? Let us jump into some code in order to understand this. Allow me to use the example of my favorite ‘PizzaStore’ class.


Public class PizzaStore
{
    Public ChickenPizza Prepare()
    {
        ChickenPizza pizza = new ChickenPizza();
        return pizza.Prepare();
    }
}

In the light of Dependency Inversion Principle (DIP) , this is not the right way of doing it. For every new Pizza class that is created in the system there needs to be a new PizzaStore class. This is because the PizzaStore class depends upon the Pizza class. A desirable design goal (according to DIP) here would be that the Pizza and the PizzaStore class should be decoupled in a manner that same PizzaStore class should be able to work with different types of Pizza. In other words, the dependency between Pizza and PizzaStore should be so inverted that PizzaStore should not directly depend on Pizza class. As a matter of fact, according to DIP, it should depend on an abstraction (IPizza interface in this case).


Public class PizzaStore
{
    Public IPizza Prepare(IPizza  pizza)
    {
        return pizza.Prepare();
    }
}

The client program must take pass the right dependency (instance of pizza) to the IPizza. This tecnique of injecting the dependency from outside is called Dependency Injection.

If we separate out the piece of code that assumes the responsibility of inverting the flow of control of the system in comparison to procedural programming using the technique of Dependency Injection, we would call this piece of code an IOC Container.

An IOC container, at the very basic should be able to do two things
• Register a Dependency
• Resolve a Dependency

For the ease of understanding, let us start with the Resolve part. Take a look at the following code,


public class PizzaStore
{
    Public IPizza Prepare()
    {
        var pizza = Container.Resolve<IPizza>();
        return pizza.Prepare();
    }
}

Here the Container determines and returns the right instance of the Pizza. Hence, whenever an instance of the type Pizza is required by the PizzaStore class, it will request the Container to resolve and return the right instance for the Pizza. This means that it is the responsibility of the Container to instantiate a class. This also means that the Container needs to have the information about what instance should it return for a given type. This is when the Register part comes into picture. The Register method tells the Container what object should be returned for a given type.


ChikenPizza chkPizza = new ChikenPizza();
Container.Register<IPizza>(chkPizza);

Or sometimes,


Container.Register<IPizza>(ChikenPizza);

Most of the existing IOC containers allow an ability to Register through configuration also. A typically full-blown IOC Container also provide with other sophistications like managing the scope and lifetime of the instance. For example, would you like your object to be instantiated on per call basis, or per thread basis or should your instance be a singleton instance.

In a nutshell, all that an IOC Container essentially does is know what instance to be retuned for a given type and then return that instance through an abstraction (generally interface) using dependency Injection.