Limitations of user stories

User story is one of the ways to communicate software requirements from user to the developers. User story is used for requirement gathering in agile software development project such as extreme programming. In general user story is a short goal oriented story on how a user will perform certain tasks with the system. Commonly, a user story contains the context of certain task, condition which triggers this user story, and script which illustrate how user do the tasks on step by step basis. User story should be flexible and free from any decision making such as user interface design choice. This user story will act as an agreement between the user and developers on the software being developed.

User story is a simple way to express the behavior or characteristics that user needs. It hides all of the complexity and focus on how a certain task can be performed. User story looks fit into agile software development practices. That is why it is used to specify requirements in extreme programming. However, user story is not a perfect tool. It has some limitations. This blog will discuss what the limitations are and show any solution to minimize the constraints.

One of the main limitations of user story is that it opens for many interpretations. User story is simple and contains scripts which focused on a functional goal. It does not state the detail of the user interaction with the system. Our customer may have different understanding with the team. As a result, it is hard to use user story to act as an agreement between the user and developers. That is why it is suggested that the customer or end user is part of the team, so that we can communicate and clear any doubts through face to face communication.

For example, if we have user story on a manager who want to send out a survey to his staff. The first story or first action in the script will be the manager would select the option to survey staff. One developer might implement this user story with a button to choose the survey staff, and other developers might use drop down list. As we can see that user story is straightforward, plain and free from any design (decision making). It will focus on capturing user requirements and try to be free from any user interface design, so that it can be implemented in many ways. We can solve this problem by discussing the design with other developers and sketching user interface design before we implement a user story.

The simplicity of a user story also causes another limitation. It lost the performance requirement detail. Often, user story which becomes the basis of user acceptance test will only test the business logic of our application. It will not test the performance or our database layer such as database response time. To overcome this limitation, developers or testers need to pay attention to other documents such as product attributes and system constraints when building the test case. Therefore, developers and users have to develop these documents carefully as it will accompany the user stories.

What is the optimal team size and composition in agile projects?

Agile software development project is a conceptual framework in software engineering where software is built within a relatively short period of time and has several iterations which yield stable release of software. Iteration usually takes one to four weeks and it depends on the type of the project. At the end of the iteration, we will have fully tested and working product. One of the key concepts in agile development is face to face communication to speed up the software development. Unlike communication over written documents which take ages to write and most of the time no one will read most of these documents.

As we know, agile project is done in relatively short period of time compared to other software development methodologies. To achieve the agility in a project, many articles, books, and agile practitioners suggest small team with consists of around seven people. There are also many recommendations on the mixture of skills within an agile team. Many people always try to tweak their agile team configuration, so that they can get the best outcome. This blog will discuss the optimal team size and composition in agile projects.

Generally, most of us will agree that more people equals to more productivity. Similarly, business people or our customers often ask us to add more people to increase the velocity of our software development project. Increasing the number of people in a software development will increase our performance, but at some point it will degrades our team because we need more coordination and communication to integrate many people. In agile projects, we always emphasize face to face communication and we often do standup meetings. In my opinion, small team which consists of seven people will perfectly match these concepts. Several developers might argue that we can still do agile project with big number of people, by dividing them into smaller self-managed team. However, I do not agree with this statement, as you are still required to integrate the work between teams and it is still difficult to communicate between small teams.

In term of team composition, a mixture of people with different set of software development skills is the best option. The reason behind this is an agile team should be self contained and self managed. The team also needs to do the entire software development iteration. The team should not ask for help from external resources or get any intervention from outside. Therefore it is good to have mixture of skills (analysts, developers, management, testers) within a team. Another issue in this area is the developer’s level of skill. Can we combine beginner with expert and experienced developers? Personally I prefer agile team which consists of expert or experienced developers only, because we do not need to educate other team member. In addition, agile team needs to take decisions fast which are possible if the team members have already had experiences in software development before.