Use Cases or User Stories?
Murali Krishna tells us: Failure to effectively transition to Agile development is often based on a fundamental failure to understand what a User Story is. The most important aspect of a User Story is that it's an independently *schedulable* unit of requirement (feature). The key to achieving the "independently schedulable" characteristic of a user story is that you express it in terms of how a "user" would use it. This leads you to a unit of functionality that's implemented end-to-end (UI to backend) that a user can actually interact with. Murali mirrors what many in the Agile community believe - that user stories are the only/best way to go and points us to an article by Mike Cohn, Advantages of User Stories for Requirements where Mike defines user stories: and then specifically contrasts user stories to the other well-known requirement technique, use cases: So it seems pretty clear that user stories are superior. Things aren't as clear cut as some would have us believe.
Agile Alliance Group News
Retrospectives and feedback loops are at the heart of any successful Agile/Scrum implementation. They’re the tool we use to help teams improve. Yet in two day introduction to Agile classes they often get glossed over. Brian Lawrence, gives a quiet retrospective format that works well for a large group or people who don’t have experience working together before. Jimmy Bosse, suggests that retrospectives are so important that no matter what happens they’re always required. Yves Hanoulle, replied saying: For me saying “NEVER stop retrospectives” is wrong. Doug Shimp, was asked the question: Should notes from the retrospective be posted publicly. Jason Little, set about creating a retrospective room for an occasion when one coach can’t be everywhere. Nice big room with lots of open area. Jason’s sample agenda: The Agile Retrospective Wiki has a number of activities that aren’t well known including: Christopher Avery has written about the subtle benefits of Retrospectives:
Working with the Product Backlog
Agile Product Management with Scrum is the product owner’s guide to creating great products with Scrum. It covers a wide range of agile product management topics including envisioning the product, stocking and grooming the product backlog, planning and tracking the project, working with the team, users and customers, and transitioning into the new role. This article is an excerpt (Chapter 3 'Working with the Product Backlog') from the book; it introduces the product backlog together with its DEEP qualities. It explains how product backlog grooming works, shares advice on discovering and describing product backlog items, and on structuring the product backlog. ScrumMasters, coaches, team members will also benefit from reading the extract as managing the product backlog is teamwork in Scrum. Few artifacts in Scrum are as popular as the product backlog. This chapter discusses the product backlog along with techniques for effectively grooming it. The deep qualities of the product backlog
All About Agile: How To Implement Scrum In 10 Easy Steps
INVEST in Good Stories, and SMART Tasks | XP123
(French) In XP, we think of requirements of coming in the form of user stories. It would be easy to mistake the story card for the “whole story,” but Ron Jeffries points out that stories in XP have three components: Cards (their physical medium), Conversation (the discussion surrounding them), and Confirmation (tests that verify them). A pidgin language is a simplified language, usually used for trade, that allows people who can’t communicate in their native language to nonetheless work together. User stories act like this. But what are characteristics of a good story? I – IndependentN – NegotiableV – ValuableE – EstimableS – SmallT – Testable Independent Stories are easiest to work with if they are independent. We can’t always achieve this; once in a while we may say things like “3 points for the first report, then 1 point for each of the others.” Negotiable… and Negotiated A good story is negotiable. Valuable A story needs to be valuable. This is especially an issue when splitting stories.
Agile Techniques: Getting Started With Kanban
As agile software development methodologies become more familiar within mainstream IT organizations, agile practitioners have been experimenting with some of Agile's Lean roots. One lean practice that has gained traction with many agilists is a Kanban board. Lean has much in common with agile. Lean has two principles, add value for your customer and empower your workers. If we look at the Agile Manifesto's 4 we can see similarities between the manifesto and Lean principles: [login] Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Agile techniques emphasize empowering individuals on the team, as evidenced in the phrase "Individuals and Interactions over processes". Teams looking to lean principles have been able to use Kanban boards both within existing agile structures and as a process that stands on its own. Organizational Buy-In
Scrum : ça ne marche pas votre truc !
Back to Waterfall !!!! J'entends, je vois et je constate ceci : On a fait tout ce que l'on avait lu, on a dit tout ce que l'on avait à dire, on fait du Scrum et notre constat est que ça ne marche pas. Voici quelques résultats des mauvais fonctionnements que j'ai pu constaté. L'équipe L'équipe n'était pas dédié : elle était partagé entre plusieurs projets non Scrum. Donc pas d'implication de l'équipe pas ou peu d'esprit d'équipe Le contenu du Sprint On l'a dit, on le répète, le contenu du Sprint ne doit pas bouger et lors de mes audits, je vois que le "Product Owner" n'hésite pas à modifier le contenu du Sprint, les fonctionnalités, ce qui est attendu. Un objectif qui bouge tout le temps est un objectif qui ne sera pas atteint. La vélocité Bah c'est simple, à chaque fois elle n'était pas calculée !!!! Les estimations Les estimations n'étaient pas faites par l'équipe mais par "l'ancien chef de projet". Confiance et Transparence Aucune ou peu de confiance entre l'équipe, le PO et le ScrumMaster.
Agile Software Development: Writing Good User Stories
Over the last few weeks, I’ve written alot about writing good User Stories – you can see them all here: User Stories . User Stories are a simple way of capturing user requirements throughout a project – an alternative to writing lengthy requirements specifications all up-front. As a guide for people writing User Stories, they can follow this basic construct: As a [user role], I want to [goal], so I can [reason]. This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why. As well as capturing User Stories in the above format on the Product Backlog , User Stories should be written on a card . The card comprises 3 parts: Card (i.e. the bit above, “as a user, I want…”) Conversation (notes and/or small wireframe to remind people about the feature) Confirmation (the tests that will show the feature is complete) Here’s an example User Story for you to take a look at. Ultimately, User Stories should be small. * Independent . * Negotiable .
