program selection system

Is your agile project buried under a mountain of user stories? As you add stories, does your vision of the product you’re building grow hazier? As story count increases, do business stakeholders become more frustrated with prioritization? Do you find it difficult to communicate the big picture of what your system does?

User stories play a central role in Agile requirements, planning and implementation. However, experts have different formulas for crafting stories and teaching others how to do it.

In this session, Jennitta Andrea, Gil Broza, Mike Cohn and Ron Jefrries will share their unique, similar or different perspectives on such issues as:

• Format: Do stories have a typical format or does that just get in the way?
• Scope: What is / is not a User Story?
• Size: Does size matter?
• Splitting: What is it? Is it needed? If so, when?
• Authors: Who writes or changes User Stories?

Reasonably accurate estimation of user stories is necessary in order to provide the customer with development schedule predictability. Small stories are usually fairly easy to estimate, but estimates for larger stories are often accompanied by higher degrees of uncertainty. Although a large story may sometimes be broken down into smaller stories for purposes of estimation, this is not always the case.

This workshop proposes a method for enabling a team of developers to rapidly quantify the relative complexities of larger user stories by using “tests” as the unit of estimation.

Being a product owner is a difficult job. BT has been using product owner teams to manage the details of “what should be built”. These teams own the content and the breakdown of user story epics into user stories for delivery teams and act as proxy customers to those delivery teams. This experience report examines a project, implementing an up to 24Mbps service over the 21CN network, which was successful in applying the approach and concludes with some advice on how best to apply Product Owner Teams.

Gathering and writing “User Stories” is always a challenging activity and interview skills are the primary factor that makes the activity effective. In this session, I propose a method for exploring “User Wish” — user’s vague ideas before shaping user stories — using semi-structured interview with mind maps. The former half of the session is an introduction of mind maping and how to use it in user story exploration. The latter half will be a demonstration and workshop of attendees.

• What is a Mind map and Why ?
• How Software Development Benefits from Using Mind Maps

I’m not sure why but somewhere along the way User Stories were branded ‘agile’ and Use Cases largely relegated to a high ceremony tool for non-agile methodologies. This talk sets out to challenge that view by suggesting that both User Stories and Use Cases could, and should, co-exist as complimentary techniques in effective agile methodologies.

Extreme Programme exige du “Client XP” d’écrire des User Stories. Un format commun est “Comme <role> je veux <quelque chose> pour atteindre <un but>.” Est-ce que vous avez des difficultés pour trouver les roles, quelques choses et buts?

Est-ce qu’un client vous a déjà demandé d’implementer une solution, pour conclure “c’est bien ce que j’ai demandé, mais ce n’est pas ce dont j’ai besoin”? Est-ce que vous avez déjà eu de difficultés pour impliquer des intervenants importants dans vos projets? Est-ce que vous avez déjà eu de la peine pour vous mettre d’accord sur les critères de recette? Est-ce que vous avez travaillé sur un projet sans vision commune, où tout le monde allait dans une direction différente?

Si oui, la technique d’interview des “9 cases” peut vous aider à partir du bon pied.