Description

• the quality of the software being written
• the efficacy of the development process
• the satisfaction of the customers and the developers

In addition, iterative development processes rely on stories to define the work that needs to be done in the iteration. These stories are told from the perspective of the customer, and allow the team to focus on the customer’s needs as it implements the system. When these stories become too large it becomes much harder

• to estimate accurately
• to track the progress of the iteration accurately
• to keep the team focused on the customer needs rather than infrastructure required to implement the big story

The processes of unfolding requirements into stories is a process of discovery which allows those that engage in it to

• to understand the true nature of the requirement,
• to realistically estimate the effort needed to fulfill it
• to agree on the acceptance criteria that will determine that the effort was well spent

• do the right thing with defects
• do the right thing the wrong way
• do the wrong thing
• miss important scenarios
• implement unneeded scenarios

All these cause considerable rework, dissatisfaction and poor return on development investment, and are usually exacerbated by long feedback cycles.

In this course we show both a process and practices to minimize these misunderstandings, enabling the team to do the right thing and to do it right.

A realistic estimate of the effort
The lack of real understanding of the requirements means that scenarios and technical considerations are overlooked. This results in bad estimates and an adverse impact on planning and organizational stress.
To be able to estimate accurately requires that all the information that is needed to make this estimate be made available. In the past that led to excruciatingly long analysis and design periods.

In this course we show how to analyze requirements correctly and just-in-time enabling accurate and quick estimates.

Agreed upon acceptance criteria
There are three classic roles in development –

• the customer – providing the requirements and domain knowledge
• the developer – fulfilling the requirements using their technical knowledge
• the tester – verifying that the system indeed does what the customer wants it to do

But what if the developer and the tester have a different understanding of what needs to be done. This will result in the system being rejected by the testers after it has been built which in turn results in rework on the developer’s end, the tester’s end, or both. The problem is that usually the acceptance criterion for the work done by the developer is not defined in advance, but concurrently or after the work is done.

In the course will show how to evolve the acceptance criteria as part of the story definition so that the chances of rework are minimized.

What does it cost?
Not much. We can achieve all of the above by simplifying the development process and without needing extra resources or expensive systems – it’s all about changing the thought process and the interactions within the team and its customers.