The importance of 'it'

What is 'it'?

It's incredible how many software organisations don't understand the importance of 'it'. By 'it' I mean the ephemeral 'it' that is 'the thing you are building'. The concept of 'it' is what holds the different engineering functions together. Without a clear, shared understanding of what 'it' is the software development process will not run smoothly.

So how does 'it' relate to the various disciplines in a software company? It should be central to them all.

From the above diagram we can see the importance of the Requirements Engineering discipline. They are the team responsible for defining the central concept of 'it' around which the entire software organisation should be centred. The health of this team is vital for the health of the entire organisation, and yet it is often underfunded, under-resourced or in extreme cases, non existent!

Agile and 'it'

No talk of requirements is complete without mention of Agile, so how does the concept of 'it' relate to Agile? In some circles (enterprise software) Agile has come to mean a set of tools or vehicles, such as, 'User Stories' and backlog management  i.e. the methodologies, such as, 'Scrum', Kanban and Extreme Programming that claim to be Agile methodologies. I have experience of development processes using a modified Scrum methodology so I will concentrate on my experience of how 'it' should be defined as a part of a typical Scrum methodology. Scrum primarily uses User Stories as the agile way of defining 'it'. However, in my opinion User Stories should only be the vehicles used to prioritise work; they should not be used to define the system. That is the job of the Use Case. So, while a Scrum Backlog may be full of User Stories, there is a separate and distinct job of work to be done to derive Use Cases from those User Stories. These will define how a system should meet a User Story in sufficient detail as  to enable the various disciplines to function effectively.

My Approach

On Alistair Cockburn's website, a certain Jim Standley (take a bow Jim, where ever  you are), suggests that, "A Story is a promise to have a conversation and a Use Case is the record of that conversation". I like that statement; it sums up the different roles of User Stories and Use Cases for me. A user story is a short description of a chunk of functionality that a system might provide to a user (actor). They can be provided by product owners, customers or other stakeholders of the system. They are the kind of statements you might hear informally in the pub, outside of meetings, in tweets or customer forums. For example, someone might say, "The admin portal is rubbish! I can't search for users by first and last name!" This would translate into a User Story something along the lines of:

"As an administrator, I want to be able to search for users by first and last name so that I can easily find Jim Smith, even though, there are hundreds of Smiths in my system."

This is a perfect fragment to put on a backlog and use for prioritisation. It has the benefits of having cost very little to produce or think about. If it never gets onto a sprint backlog (perhaps there's only one customer with hundreds of Smiths and they have found a work around), it has not cost much. However, if it is sufficiently high in priority, the product owner puts it into a sprint, then further work needs to be done to define what 'it' is that the system will do. This is where Use Cases come in. Well written Use Cases should have sufficient detail to define what 'it' is that the system must do. They can then be used to estimate, implement, test and verify the system. The translation from User Story to Use Case, may or may not involve the customer. The translation is a great time to involve disciplines, such as, human factors, user experience teams, designers, architects, safety and security engineers, if relevant to your product and development organisation. These non-functional  requirements may be built into the Use Case so that they are visible to all those responsible for the estimation, implementation, verification and testing of the 'it', described by the User Story.