Agile software development in brief
Taking down user requirements in a clear and transparent manner can be a challenge for software developers. With classic (waterfall) project management, all specifications are compiled into extensive documents before beginning with the implementation phase. Requirements are often first roughly described in a user requirements specification in order to then finalise them in a functional specification. Another variation would be to describe the functional requirements in a functional concept paper and the technical implementation strategy in a system concept paper. After the description of the project scope has been completed, the implementation phase begins. A flaw in this approach is that at the time of writing the concept papers, namely right at the beginning of the project, little is known about the requirements and preconditions.
Agile software development tries to fix this by only compiling a very rough description of requirements at the beginning of the project. In the most widespread agile methodology, Scrum (cf. e.g. State of Agile Report 2016), all requirements are incorporated in the so-called “Product Backlog” as “Features” and prioritised. Subsequently, all features are concretised in “User Stories”. We start with the highest priority feature. User stories describe the purely functional software functions. Before implementation begins, the development team gradually analyses the User Stories and assesses the scope. The advantage of this approach is that the final implementation is only designed when the implementation phase is about to begin. This way, all gained experience and changes to content can be taken into account.
With agile software development you begin with specification documents which used to only contain headings and rough parameters. The rest of the content and all details are constantly updated once development has begun.
The basic structure of User Stories is very simple. They consist of a short functional description and acceptance criteria. The functional description usually includes a sentence in this form:
In a project for developing an application for recording work times, these requirements, for example, could be defined.
When formulating user stories, it is important to make sure that they fulfil the INVEST criteria:
|I ndependent:||It must be possible to implement the User Story independently from other stories.|
|N egotiable:||It must be possible to be able to change the User Story right up until the beginning of the implementation phase.|
|V aluable:||The user story must have a benefit.|
|E stimatable:||It must be possible to estimate the scope of implementation of the User Story.|
|S mall:||User Stories should not be so extensive that it is no longer possible to schedule or prioritise them.|
|T estable:||The User Story is described in such a way that it is possible to create tests for it.|
The functional description is nowhere near sufficient to fulfil the INVEST criteria. Therefore, User Stories are added to so-called acceptance criteria. This way, both functional and technical requirements can be indicated as acceptance criteria. For the user stories mentioned above, these acceptance criteria could be stated, among others:
|User Story||Acceptance criteria|
|As department head I would like to be able to see an overview of all employees in my department in order to be able to complete evaluations.|
|As an employee I would like to be able to see my working time account in order to view its current status.|
|As administrator I would like new employees to be automatically synchronized with the home directory so that it does not have to be done manually.|
Content to be implemented by the development team is made much clearer and more precise through the acceptance criteria. The closer the User Story is to its implementation, the more precisely it must be created and the clearer the acceptance criteria must be. As soon as a story is included in a sprint, it can no longer be changed without consultation with the team. Otherwise the scope would be changed.
In Scrum the Product Owner is responsible for the prioritising and detailing of User Stories in the product backlog. In so-called backlog refinement meetings, they have the possibility to discuss stories from the Product Backlog with the development team and estimate their complexity.
New acceptance criteria are usually found through discussion with the team. If the team believes that a story is still too large for the complexity estimation or that it is not feasible in its current form, the Product Owner must divide this story into several new stories. There are lots of possibilities for this.
|Slice along from functional dependencies||Many functions must be implemented in different areas (e.g. Front- and backend) Thus only the frontend can be developed in one story and later the backend in another story.|
|Separation of functionalities that can be implemented quickly and those that are more demanding||Sometimes it is helpful when you can quickly present a part of a story (e.g. to get feedback) It is thus useful to divide the original story into several stories based on the expected implementation duration.|
|Separation along from users/rolls||In the discussion of User Stories acceptance criteria can arise from different rolls or user groups. As soon as this is apparent, the User Story should be divided so that each User Story is clearly assigned to a user group/roll.|
|Division according to process steps||Many functions consist of several process steps (e.g. registration, confirmation e-mails, first login, changing initial password). Each process step can make up a User Story.|
|Slice based on current knowledge||There are often aspects to a User Story for which there are already more precise concepts than for other parts of the story. It can thus be useful to group the already very precise aspects in a story together. This part can then be implemented and can contribute, if necessary, to improving other aspects.|
There are many more methods for dividing User Stories other than the ones mentioned above. No method of dividing is forbidden. However, for each User Story there is always one method which is more reasonable than others.
Our example stories could be divided as follows.
As department head I would like to be able to see an overview of allemployees
in my department in order to be able to complete evaluations.
|As department head I would like to be able to see an overview of all employees in my department in order to gain an overview.||As department head I would like to be able to make evaluations using the times entered by the employees of my department in order to gain an overview of the hours worked e.g. on each project.|
Method: Slice based on knowledge. It is still not known which type of evaluation is required. However, the overview of employees in a department can already be implemented.
As an employee I would like to be able to see my working time account
in order to view its current status.
|As an employee I would like that my working time hours get calculated everyday so that there is always the current status available.||As an employee I would always like to be able to access the current status of my working time hours so that I can always view the current status myself.|
Method: Division according to process steps. The first User Story includes the calculation of overtime hours. The acceptance criteria can thus concentrate on the correct calculation of overtime hours. The second User Story focuses on the request for the current status. The acceptance criteria can thus focus on displaying the correct result.
As administrator I would like new employees to be automatically synchronized
with the home directory so that it does not have to be done manually.
|As administrator I would like that employees and their attributes are regularly synchronised with the home directory so that the current data is always displayed in the application.||As department head I would like new employees to be able to enter time entries into the time record on their first day so that the employees feel welcome and do not have to enter time entries retrospectively.|
Method: Separation along from users/rolls. A new aspect, which can also generate new acceptance criteria, is imported for this User Story through the roll of the department head. This improves the use of the features.
Of course, a User Story can be divided into any number of new User Stories. When dividing User Stories, you must make sure that the acceptance criteria are also divided into the new stories accordingly. User Stories should always be sized in a manner that allows a development team to implement several stories per iteration.
The most important thing for User Stories is to discuss them in the team. It is pointless for a Product Owner to sit and write User Stories and then hand them to the development team. That would be the same as one person writing a user requirement specification. The point of discussing User Stories is to make sure that the whole team is on the same page. It is also important to record the results in writing or in pictures so that they can be referred to during the implementation phase.
Conclusion and outlook
During the course of a Scrum project, the User Stories must always be further planned, discussed and detailed on the basis of the prioritised Product Backlog. Clear User Stories which fulfil all the necessary requirements are the basis for a successful product as they form the foundations for later development. As well as content, all further INVEST criteria, such as testability or manageable size, are necessary for good User Stories. Therefore, it is important that you divide a story into several stories according to the occurring necessities and thus reduce the scope of each story to a manageable size. It is also important to use the possibility for others to look at the same aspect from a different perspective and with a different focus.