Structuring agile projects with User Stories
There are many different tools and methods available for structuring agile projects. On Entwickler.de Michael Bykovski has thought about this and provided some food for thought. He asks himself the question how an agile project can be organized and estimated before the first sprint.
In the following we summarize his article for you
In the following we summarize his article for you
From wanting to do
Behind every project is someone who hopes for something from the project or wants to achieve something. He assigns someone else to put this desire into practice. The first thing to do is to find out as precisely as possible what is actually wanted. Only the one who wants can help him. This is how Michael Bykovski describes the problem of defining a project and the project goal. Simple and clear words. But how does that work? How do you manage to convey your requirements and ideas to someone in such a way that they can implement them directly with the appropriate measures? Or how do you manage to understand exactly what someone wants?
User Stories
User Stories can be the means for structuring and implementation. How well a user story is written depends, of course, on who wrote it. If it is written by someone who can fully identify with the users or, in the best case, is a user himself, the user story can be very useful. If your client does not want to write the story himself, meet with him and gather as much information from him as possible. Divide your User Story into smaller stories to be able to deal with each individual requirement separately.
A popular example: The customer wants his users to be able to log in to his interface with Twitter, Google or Facebook. These are, translated into the language of the web developer who is to implement the requirements, three different requirements that can be seen independently of each other. The user wants to log in with Facebook. The user wants to log in with Twitter. The user wants to log in with Google. Ideally, you derive from your user story who the target group is, how much effort is required and whether the project is cost-effective. The evaluation of user stories is important to keep the process smooth and efficient. Many like to work with Confluence or Jira. User stories can be of tremendous importance when defining tasks for the project team. User Stories can replace a specification sheet and are ideally much easier to understand than endless technical lists. In addition, the customer can just as easily understand and contribute to the user story because it is written in his, in a common, non-technical language. No technical jargon. To be noted: The user stories must all be written in a common language. They must be complete. Of course, the customer can come up with additional user stories during the project. This is not a problem in agile projects, and in fact is more the rule than the exception.
A popular example: The customer wants his users to be able to log in to his interface with Twitter, Google or Facebook. These are, translated into the language of the web developer who is to implement the requirements, three different requirements that can be seen independently of each other. The user wants to log in with Facebook. The user wants to log in with Twitter. The user wants to log in with Google. Ideally, you derive from your user story who the target group is, how much effort is required and whether the project is cost-effective. The evaluation of user stories is important to keep the process smooth and efficient. Many like to work with Confluence or Jira. User stories can be of tremendous importance when defining tasks for the project team. User Stories can replace a specification sheet and are ideally much easier to understand than endless technical lists. In addition, the customer can just as easily understand and contribute to the user story because it is written in his, in a common, non-technical language. No technical jargon. To be noted: The user stories must all be written in a common language. They must be complete. Of course, the customer can come up with additional user stories during the project. This is not a problem in agile projects, and in fact is more the rule than the exception.
Customer Priorities
Now imagine that there is already a list of user stories. The example that Michael Bykovski gives describes a to-do list. The customer wants users to be able to write tasks in it, that these tasks can be shared with other users, that the tasks can also be processed jointly by users, that the admin always sees how many tasks are entered per day, that the user sees the tasks assigned to him in a database but nobody else, and that the user can add tasks to his list. First of all, priorities are assigned. There are only six requests here. But for many projects, there are often 100 or 200 user stories. So you can imagine that prioritizing is not always that easy. Here, Michael Bykovski advises to cluster the tasks.
Milestone Prio
You manage your project agile because you want to keep the implementation as flexible as possible. Nevertheless, you also have deadlines and milestones. The agile methods have a slight weakness here, because they are designed to be sprint to sprint rather than being directed towards a distant future. The principle of Milestone Prio should make it possible to provide the customer with concrete, tangible data. User Stories 1-17 will be completed by the first of May. At the meetings of the Milestone Prio there should be a representative from each area, from design, backend, frontend, conception and a product owner. Everyone must know the user stories. This is a prerequisite for a successful Milestone Prio.
Proceed in the meeting in such a way that the list of User Stories is first provided with the priorities of the customer. Then, on individual sheets of paper or sticky notes, map the timeline of the project, in weeks or months depending on the duration. First you select the user stories that can be edited independently of all other user stories. In addition, you assign which department must or will be responsible for the respective user story. Then you devote yourself to the stories between which dependencies exist and relate them to each other. The next step is to look at the stories that have been given the highest priority by the customer.
Now the order is clear: first the tasks are completed that are independent and have the highest priority. Then, or in parallel, those tasks are tackled that have high priority but have dependencies. To these are added the tasks that do not have high priority but are related to the priority tasks. Important: never leave out common sense. If customer prioritization does not seem to make sense, it can be changed. If a creative idea for improvement comes up: seize the opportunity. However, the product owner must document all adjustments - especially regarding priorities.
Proceed in the meeting in such a way that the list of User Stories is first provided with the priorities of the customer. Then, on individual sheets of paper or sticky notes, map the timeline of the project, in weeks or months depending on the duration. First you select the user stories that can be edited independently of all other user stories. In addition, you assign which department must or will be responsible for the respective user story. Then you devote yourself to the stories between which dependencies exist and relate them to each other. The next step is to look at the stories that have been given the highest priority by the customer.
Now the order is clear: first the tasks are completed that are independent and have the highest priority. Then, or in parallel, those tasks are tackled that have high priority but have dependencies. To these are added the tasks that do not have high priority but are related to the priority tasks. Important: never leave out common sense. If customer prioritization does not seem to make sense, it can be changed. If a creative idea for improvement comes up: seize the opportunity. However, the product owner must document all adjustments - especially regarding priorities.
Planning Poker
With agile projects it is often difficult to give the customer an exact budget. After all, everything can change very quickly. But you can, for example, select 80 of your 100 user stories and name a price for them. This way, the customer can get an idea of what the whole project will cost him or whether he might have to do without some user stories in order to get a cheaper project. However, even with this approach, you always have to estimate what it will cost to implement one or even 80 of these User Stories. This is where Planning Poker comes into play. Give your team members cards with numbers and have everyone put a card face down on the table, the value of which corresponds to what they estimate will take days or hours (depending on the project) to complete a task. The mean value of these estimates is often a good house number. If the numbers differ greatly, it may be necessary to discuss what the task behind the user story actually consists of.
Author: IAPM intern
Keywords: Knowledge, Tip, Agile project management, Project structuring