Limitations of User Stories

Concept

A user story is a high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort needed to implement it. It is one of the primary development artefacts for Extreme Programming project teams.

User stories are similar to usage scenarios, except that they are not limited to describing a user interface. They are in the format of about three sentences of text written by the customer in the customer's terminology, without technical or developer oriented syntax.

Argument

One of the biggest misunderstandings with user stories is how they differ from traditional requirements specifications; the biggest difference is in the level of detail. User stories only provide enough detail to make a reasonable low risk estimate of how long the story will take to implement. When the time comes to implement the story, developers will go to the customer and receive a detailed description of the requirements face to face.

Another limitation of a user story is their dependency to acceptance tests. Indeed, these ensure that it is later possible to determine whether the goals have been fulfilled. Without them, user stories are likely subject to various interpretations, which make them hard to use as a basis for agreement. Thus, they may fail to serve as a form of reliable documentation of the system.

Also, user stories can be difficult to put in place on large projects involving many developers, due to its structure and timely breakdown (Longer than 3 weeks means you need to break the story down further. Less than 1 week and you are at too detailed a level). Besides, it relies on developers' competencies, both in interpretation and estimates.

Implementing user stories in a project also requires close and regular customer contact, as they are likely to be updated and modified throughout the project. In some cases, this may be difficult to achieve, not to mention any financial impact on the project's budget and the eventual unnecessary overhead.

Conclusion

Because user stories contain so little information, we need to flesh them out when we first work with them. During the estimation effort, it is common to list programming tasks required to implement the user story. When we start to working on implementation, we may decide to create some rough sketches of what we are going to build, like a screen mock-up or a UML activity diagram representing the relevant business logic. User stories are merely the starting point.

TEST DRIVEN DEVELOPEMENT – When to, When not to

Concept

Test Driven Development (TDD) is a lightweight programming methodology that emphasizes fast, incremental development and especially writing tests before writing code. Ideally these follow one another in cycles measured in minutes. TDD is one of the core practices of Extreme Programming (XP).

Functionality in TDD is added in very small chunks. Typically the first cycle will deal with quite simple cases. Once we have these very simple tests working, we add more functionality, a bit at a time.

It can be basically seen as a three-step approach: write test, write code, refactor.

Argument

Test Driven Development can be used as long as the specifications are clear enough to let us write tests that would the software’s compliance. From there on, we can start writing the software.

It can also be used with existing software projects, but this would not be necessarily easy. Indeed, the larger the software project, the larger will be the blocks of untested code at the core. We could just write a huge test to exercise the block of code, but again this will be time consuming, subject to fail, and is also against the TDD spirit.

A good practice would be to concentrate on using TDD with any new project code, and regularly refactoring what already exists, breaking it in smaller piece of code over a period of time.

The use and implementation of TDD also depends on the size of the project as said earlier. Indeed, because TDD emphasizes on flexibility and fast turnaround, it is mostly used in projects involving no more than a few dozen programmers.

Also before getting into the TDD process, people have to lean it. This depends upon the individual and the circumstances. Basically it is a matter of developing a new habit.
On the other hand, we might find that it's best to learn it with someone else. If you can pair off with someone experienced with TDD, this can be especially beneficial.

To conclude, some practitioners believe that TDD cannot be used in developing multi-threaded code, or where security is a key consideration. Some arguably disagree with both of these conclusions. For best results, of course, TDD relies upon good relations with the customer and well-conceived specifications.

Extreme Programming vs. Scrum

Concept

Extreme Programming is a discipline of agile software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they currently are in the development process, and to adjust the practices to their unique situation.

Scrum is an agile process that can be used to manage and control complex software and product development using iterative and incremental practices. It significantly increases productivity and reduces time to benefits while facilitating systems development.

Argument

XP is successful because it stresses customer satisfaction. The methodology is designed to deliver to the customer the software he needs when it is needed. It allows the developers to confidently respond to changing customer requirements, even late in the life cycle.
This methodology also emphasizes on team work. Indeed, Managers, customers, and developers are all part of a team dedicated to delivering software that meets quality requirements. Practices used include targeted unit testing, refactoring, small releases and use of spikes.

Scrum, on the other hand, enables the creation of self-organizing teams by encouraging verbal communication across all team members and across all areas involved in the project. One of the key principles of scrum is its recognition that “empirical” challenges cannot be addressed successfully in a traditional "process control" manner. Hence, scrum adopts an empirical approach - accepting that the problem cannot be fully understood or defined, and instead focusing on maximising the team's ability to respond to challenges using an agile approach. This process includes the use of product backlog, daily scrum meetings, sprint planning and backlog.

Even though both XP and Scrum are radically agile methods, and Scrum often uses methods and practices coming from XP, they differ in some points. In fact, XP seems to focus on team productivity (i.e. doing something the right way and as productively as possible). Scrum instead focuses more on doing the right thing, getting the Risk on Investment from building the 20% of the functionality that is necessary to get the value and maybe not building the rest.

Also, the XP approach emphasizes on estimations, like finely defined user stories, and to measure and improve these estimates.
Scrum keeps the requirements more extensive, more in general user terms analyzed during the iteration. Estimating is not as important as in XP. The team does what it can, and gets better at figuring out how much it can do each iteration as it learns each others skill sets, the business domain, and the technology - iteration by iteration. It cares more about delivering business value than having estimates, which become meaningless in a collaborative setting.