The main claim of agile methods is to emphasize iterative processes, continuous improvement and the early incorporation of customer feedback. In contrast to traditional, waterfall-like approaches, in which the requirements are defined comprehensively at the beginning and then implemented step by step, agile methods welcome the gradual increase in knowledge on the customer side and in the team. In contrast to the idea of being able to firmly define the requirements at the start of a project in waterfall models, this requires a continuous stream of changes. If implemented correctly, this ultimately leads to a product that is better adapted to requirements in a shorter project lead time. Agile methods also aim to systematically identify "work that does not need to be done" in order to achieve high development performance. This means that tasks with little or no added value for the product are not simply accepted with a shrug, but actively avoided.

Being agile - easier said than done

This view has now arrived in many companies; Scrum or Kanban have often established themselves as concrete agile procedures in product development. However, "being agile" is often easier said than done and so, despite the advantages, agile product development naturally also brings with it considerable challenges. Precise communication and transparent collaboration with stakeholders and within the development team are crucial to success. The continuous, prompt and detailed preparation of information and rapid decision-making required for this are tasks that are often perceived as laborious and time-consuming by all roles involved in everyday agile work.

Generative AI to simplify agility

This is where generative AI comes into play. With the ability to process complex texts quickly and generate text suggestions, the communication level of agile product development is very well supported and the actual ability to react within the team is improved. Looking at it the other way round, from the perspective of generative AI, the small-scale nature of information processing is the key to its efficient use. The small-scale, clearly defined context and the well-defined formulation goal in relation to agile description artifacts are good prerequisites for prompts with high quality results.

As an example from the different levels of abstraction (Figure 1) of how project goals, product capabilities and characteristics, work packages and tasks as well as concrete specifications can be formulated in agile projects, the following section will break down epics into user stories.

Basically, epics and user stories are used to describe work packages. Epics are used for large work packages that still need to be broken down into a more detailed description, i.e. into user stories, for concrete processing (Figure 2).

A prompt recipe

Figure 1: Different levels of abstraction to describe an agile development project.

© selim/stock.adobe.com / talsen team

As a basis for our prompt recipe for breaking down an epic into user stories, let's remember the general approach and what information a prompt should contain:

A good prompt is roughly equivalent to giving work instructions to a person who has the basic skills to accomplish the task, but has no specific information or context about it.

Let's remember the structure of our standardized prompt for contextual information and actions. Last but not least, we need a template for a user story as a target format for the generative AI. The example to be broken down now has the usual format for epics and consists of a title, a narrative, several acceptance criteria and a short description:

• Epic Title: First implementation of a proof-of-concept of an IIoT application for collecting temperature data
• Narrative:
  • To enable real-time monitoring and make informed decisions immediately,
  • as a production plant manager,
  • a system that continuously collects temperature data from the production process and displays it on an intuitive dashboard.
• Acceptance criterion 1: Sensors must be able to continuously monitor the temperature in the production environment.
• Acceptance criterion 2: There should be a reliable data collection and transmission service, ...
• Acceptance criterion 3: Description: This Epic includes....

Our blank template for the one or more user stories to be created as the target format is as follows. The text in "<>" brackets will be replaced by the LLM later:

• User story title: <title comes here>
• Estimate: <the estimate with the desired scale comes here>
• Narrative:
  • To <goal or benefit to be achieved comes here>,
  • I would like to be <role/persona comes here>,
  • <desired product function / product characteristic comes here>.
• Acceptance criterion 1: <acceptance criterion comes here>
• Acceptance criterion2: <acceptance criterion comes here>
• Acceptance criterion3: <acceptance criterion comes here>
• Description: <description of the user story comes here>

This completes the building blocks for our decomposition prompt for the first acceptance criterion. The epic and the format template are abbreviated in the example prompt to save space. If you would like to try out the recipe yourself, please add the relevant information and templates to the decomposition prompt and complete it. The entire process is illustrated as an overview at the beginning of the article ("The schematic representation of the prompt process").

Complete prompt with all required information parts:

# given the epic
```
Epic title: see above for specific wording ...
```
# given
```
The additional context required to successfully break down the epic into one or more user stories must be added here. Further context would be, for example, relevant personas, relevant technology specifications and decisions, relevant architecture specifications, information on existing intermediate results or examples to be considered, information on the existing code base to be considered - simply put, all information that would also be used to successfully commission a person with the task.
```
# give the format template of a user story
```
User story title: template see above
```
# then
* analyze the given epic and the additionally given situation- and task-related context,
* formulate one or more complete user stories for the X. Formulate one or more complete user stories for the X acceptance criterion of the epic that describe and cover the concrete implementation of this acceptance criterion,
* use the given format template for user stories as the format,
* do not change the structure of the format template, but only insert text in the placeholders marked with "<>",
* always formulate a user story with at least three acceptance criteria, but never formulate more than five acceptance criteria,
* the scale for the effort estimation is: small, medium, large, very large

The required actions in the "then" block comprise several criteria that are separated and structured into individual bullet points. It is a good idea to focus on one aspect of the breakdown, as only one acceptance criterion is requested here for further detail. If the expected answer is too long or if too broad a thematic field has to be covered, generalized answers can be expected, which have a lower utility value. It should also be noted that this way of working can quickly lead to information overflow. To avoid this, you should start with the most valuable, critical and useful acceptance criteria in line with an agile, value-based approach and only formulate and break down the remaining acceptance criteria when there is a specific need. The goal of an agile approach is not theoretical completeness, but maximizing the value created per unit of time.

The prompt result

Figure 2: The continuous breakdown of requirements information into ever smaller and more precise task descriptions.

© selim/stock.adobe.com / talsen team

To say it up front: You shouldn't expect any magic from generative AI. On the contrary: product owners and the development team will have to critically review these formulation suggestions in terms of correctness, relevance and completeness. However, with a well-chosen context, the formulation result generated in this way is surprisingly good and offers advantages over a purely manual formulation for the following case studies:

• Quick further decomposition and detailing of work organization artifacts such as epics and user stories.
• No "blank sheet" effect to quickly generate a formulation proposal.
• Democratization of good formulations - not only product owners and product decision-makers can now create high-quality descriptive documents, but everyone in the team.
• Better initial formulations regardless of the linguistic capabilities of the team member.
• Easier and more direct criticism in the team is possible, as formulation suggestions come from a neutral (AI) instance and not from the team.
• Simple translation of texts into all conceivable languages for internationally mixed teams.
• The same principle can be applied to the rapid creation of text-based high-level requirement descriptions.

Conclusion and outlook

The author: Dr. Hans Egermeier is Managing Director of talsen team.

© talsen team

The example chosen for this article is only a small excerpt from the descriptive development documents of a development process. However, the principle can easily be applied to the other levels. A working method with clearly structured levels of abstraction has proven to be particularly beneficial when interacting with generative AIs. This makes it easy to compile the necessary context for high-quality prompts that bring practical benefits to agile teams in terms of a benefit/effort analysis. The next part of this series of articles will explain how these advantages can be used from the requirement down to the code level.