Social Web

Wat is dit? Vanaf deze pagina kunt u gebruik maken van de Sociale Web links om Story != Usecase and other important details op te slaan naar een sociale bookmarking site, of het E-mail formulier gebruiken om een link te verzenden via e-mail.

del.icio.us	Digg
Furl	Netscape
Yahoo! My Web	Technorati
Google Bookmarks	Newsvine
BlinkList	reddit
Blogmarks	ma.gnolia
Tailrank	Windows Live
Linkedin

Geplaatst op 12 December 2009, 16:58 door Mark Kikken in project management, requirements engineering, agile

One might assume that a story used in agile methodologies and a traditional usecase are in fact the same thing, except for the fact that stories are less elaborate descriptions of system behaviour than usecases. I recently discovered that there is a more important difference between the two. I discovered this wile working on a typical non-agile project. But let me first explain my understanding of the concept story and the way planning is done in agile projects.

 

In an agile project, a story is tight to a requirement. These requirements have been expressed by the customer as short descriptions of what a user should be able to do with the system. Stories usually come to life in the form of a proto-story: a vague description of a major system capability. For our imaginary project X this could be something like this:

·        "Story 42: The user views data from system Y (priority 100)"

Planning meetings are held on a regular basis: every 2 weeks. During these meetings the customer expresses his wish to have story 42 implemented, but the team still does not know how to do this and therefore assigns a lot of storypoints to story 42, thereby indicating that it will be difficult to build. In this project 40 is a high number of storypoints, and 40 is what is assigned to story 42. Since this means that the functionality is probably not buildable within 2 weeks, the customer has to either postpone the story, or give a more detailed description of what is to be built. Detailed descriptions are given by splitting story 42 in 3 pieces:

·        "Story 43: The user views a document from system Y (priority 110)"

·        "Story 44: The user searches for documents from system Y (priority 105"

·        "Story 45: Only the supervisor user will see top-secret documents from system Y (priority 101)"

Note that these new stories are all functional descriptions of what the system should do, one should avoid creating non-functional stories like "Migrate all data from system Y", since it is very difficult to verify if these have been implemented. Besides, the team members are capable of splitting a story into tasks, and can therefore decide themselves if they will use an example document for story 43 and do the data migration in story 44, or the other way around, which improves the team's flexibility and capability to manage itself.

To these new, more detailed requirements the team assigns the following storypoints:

·        Story 43: 13

·        Story 44: 5

·        Story 45: 8

Not only has the total number of storypoints decreased as a result of a better description of what to build, it is possible to build story 43 and 44 in the next iteration, since we know from experience that the team will be able to deliver about 20 storypoints within 2 weeks.

The process of splitting proto-stories into smaller stories is an important one. If this is done correctly, it will keep you from making detailed estimates for things that you don't even know the details of. Still, a vague estimate is available in the form of the storypoint estimate for story 42. The following diagram will recap the agile planning process:

 



 

Now, let me introduce the not-so-agile project I mentioned before. This is a fixed-price, fixed-scope project. The scope has been made fixed by writing the requirements down in a requirements document and having the customer sign it. We assume that these requirements will not change, but we know better. Still, the deal is that we will build what's in the document, so that is what we are going to do. A satisfied customer is an important, but secondary priority. After all, the customer required us to have a fixed scope, or else he would not have trusted us with the project.
The requirements document groups the requirements by assigning them to usecases. As well, a time-plan has been made for the entire project. This plan has been made on the task-level. These tasks have been grouped by deliverable. So, trying to make sense of this, I assumed the following: A usecase is like a story, which can be split into tasks. A deliverable is like a system component. A common mistake made is to plan ahead on a task level and by component, so this is what I assumed. It was worse though. I will draw a diagram of all the entities involved in the planning effort:



A couple of things are seriously wrong with this model:

• A deliverable turns out to not be a component, but something that could be described as a non-functional-proto-story. Something like "base functionality" or "import data from system Y". These deliverables describe system behavior but are not usecases.
• In an effort to plan ahead, steps (and bricks) have been introduced to map tasks to stages of development. A deliverable can be completed in multiple steps, so tasks may have to re-occur in the same deliverable, but for a different step. Note that there is no guarantee that all tasks to complete a step are in the deliverable. We might face some unpleasant surprises. The agile approach minimizes this problem by not planning ahead too far and planning frequently. That way functionality already built can be taken into account when planning. For example, after implementing story #44, you will take into account that adding a new document type might impact this search functionality. It is very difficult to know in advance what has to be adapted if the part that has to be adapted is not built yet and critical design decisions have not been made yet.
• Most of all, the problem here is, that a usecase is not directly related to tasks. Because of this, we simply do not know if we have implemented all functionality once the usecase is done. The deliverable might contain tasks that we overlooked in the usecase. Finishing all tasks will not guarantee anything at all as well, since tasks describe what the developer should do, not what the system should. Therefore, I cannot draw a time-diagram like I did for the agile example: it is way too easy to miss something if only one type of entity is included. I also cannot convert all entity types (tasks, usecases, requirements and deliverables) to one type, let's say requirements: how would I know which tasks belong to which requirement? It is even very likely that tasks have to be split or discarded, for this to work.

We are trying to solve this by keeping an eye on deliverables, tasks and requirements at the same time. But to me, this feels like fighting a multi-headed dragon.

 

I will end this rather long post with my view on the actual difference between a story and a usecase. Usecases typically describe a user interaction aspect of the system. However, there is no guarantee that all implemented usecases together describe the behavior of the entire system. All implemented stories together should completely describe the system's behavior. Furthermore, a usecase cannot necessarily be broken down into developer tasks. For stories, tasks describe how to implement that particular piece of system behaviour. With usecases, a task is something to be done to get the entire system working; multiple usecases might depend upon it.
There is a reason for this: planning far ahead on a detailed task-level requires you to create dependencies between tasks. These dependencies make it impossible to assign a task to just one use-case: that usecase would include almost all tasks since most tasks depend upon eachother. My advice: don't plan far ahead on a detailed level; just use the details as input for a rough, high-level estimate that will be broken down once the details emerge.

---