Building blocks of agile modeling

I have heard tons of time the term agile modeling from other developers both in my team and in other teams, with this small article I don’t want to create a reference for the agile modeling process (there are already a lot of resources on-line) but I want to point your attention to some terms and to the procedure I’m used to use during the development of Flex projects.
One of the main issues during the live cycle of a project is the communication between the customer and the development team, what you need is an easy and agile way to define the functionalities of the software that enables the two teams to understand the goals of the project and eventually to change the scope of the features planned for each release.
In order to avoid a situation in which the customer and his team make one all-encompassing set of decision at the beginning of the project you can start to use stories and spread the decision making across the duration of the project.
An user story describe in a very short way a functionality that will be valuable for the customer using a jargon that is not too much technical, moreover a story can be used to track the activity of the development team and to keep track about the conversation between the two main actors of a software development project: the customer team and the development team.
Traditionally the stories are hand written and pointed on a dashboard, so the use of stories is not a way to document a project but a way to represent customer requirements in a very informal way.
In order to write a story that can be useful for the project you have to avoid to put technical statement inside the story, the reason why is that the technology stuffs are related to developers only.
Imagine the simple scenario in which you have to describe the login form of an application, you can put in place these stories

The first three stories represent a good example, the last one not because this is something that the application need to do but not something that can be clear for the two actors of the development process, move this in the technical specification that will be based on the stories or remove it completely because is quite obvious that some server side interactions are needed in order to run an application.
The key point here is that stories have to be written in a way that customer can evaluate them, project managers can understand them and developers can easily provide information about the time they need to implement the feature.
Sometimes stories are not so simple, imagine if you have to write down stories for a research form in which the user can select multiple and sometimes complex criterion, the functionalities the user can use may be represented with more than a story (remember that stories have to be short), in this scenario you can group them under an epic; an epic can be split into two or more stories (actually I suggest to keep 10 as the maximum number of stories under each epic).
Don’t incur in the mistake to split stories in too much epic and stories until you are able get a story that define all the details, details are a task for the technical specifications that usually (but not always) come after the customer and the development team have complete the stories / epics exercise.
When one of the team need to discuss some details add a note to the story inside the story itself

but keep the note as a part of the story itself and if you discuss the story with one of the two teams add relevant information as part of the note.
When you have a story completed you can also add some information about how to test the story, in the real world you can do it writing the tests on the back of the card, otherwise if you use some web application 99% you this option. If you are using another tool you can put the test in a box connected to the story and use the green as the color background.
In order to plan a release with the customer you can put a set of story in a pile (also an Excel file is good enough) in which the stories priority is based on the pile order and use the estimation for the delivery that each developer put on a story in order to understand when the release can be deployed.
If the pile time is not satisfactory for the customer you can split the stories in more than one pile, each pile now represent an iteration of the live cycle of the software.
The time the development team needs to complete a iteration represent the speed of the team and this factor will be the one that a project manager can use to plan new release with the customer without asking a continuous opinion to the development team.
In order to write a good story you can rely to the Bill Wake definition, a good story is
•    Independent
•    Negotiable
•    Valuable to user, customer and developer
•    Estimable
•    Small
•    Testable
Each story has to be as much as possible without any dependency on other stories but if you can’t remove the dependencies you can combine the dependent stories into one larger but independent story or you can find a different way to split the stories.
Stories are negotiable, they are not written contracts or requirements that the software house must implement, stories are short descriptions of functionalities the details of which are negotiated in a conversation between the customer and the development team.
With this approach you can avoid the situation in which a customer is afraid that during the development process everything he said can be used against him.
Actually the stories are a reminder for the developer and the customer to have a conversation then they have to be no more than one sentence or two with some possible notes.
A story has to be valuable for different purposes and so have to be written with a jargon that is understandable for the customer team, the development team and the test users, the best approach is that the customer write the stories but that is not possible the development team have to handle this task carefully.
It is important that the developers are able to estimate the effort to design and develop each story, if the developers or the customers don’t understand the story this is a good starting point for the project manager to write down the agenda of the next meeting.
If the estimation is not possible because there is a lack of knowledge the team can move one or two members on spike, a spike is a brief experiment to learn about an area of the application that is not clear.

Remember always to keep stories small, epics are sometimes difficult to handle but they can be used as well (not too much!).

Stories must be written in a way that make them testable, I mean that a story can be used as a blue print for the unit testing and for the user test, a story is not testable when it comes from a non functional requirement.
Following this building blocks you’ll be able to write good stories and to start to define estimates for each one, the web is full of resources about that so feel free to investigate and learn more on this topic.



Leave a Reply

Your email address will not be published.