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:
Attending a Scrum master training course … an event that started some critical thinking at the back of my mind - Part 2/2 - Willy's Reflections
Continued from Attending a Scrum master training course … an event that started some critical thinking at the back of my mind - Part 1/2 which summarised the why I was on this course, some of my objectives (questions, scrum smells, etc.) and introduced changes to the Visual Studio ALM Rangers Scrum Poster. Day 2 … today was a phenomenal day and thanks to Chris, we had a very interactive day … we subsequently ran short on time and had to rush through the “slides”, but then the consensus was that the interactive nature was far more valuable. Most of today was spent going through planning and retrospective activities, including multiple teams, which kick-started the critical thinking even more. I do not have final answers to my questions as yet, but have decided to invest energy in this topic and possibly work on a whitepaper with a title such as “Schizophrenic scrum guide to distributed and virtual teams”. Your opinions and comments are welcome to the above!
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
The Easy Way to Writing Good User Stories
Many development shops have opted to writing user stories over traditional feature/requirement documents; however, almost all of them struggle when writing their first batch of user stories. This is not at all uncommon, just like riding a bike, it does take a little bit of practice (but once you get it – you get it). Writing user stories is dead simple if you follow these simple steps: 1. When writing user stories, using this pattern is a for sure bullseye. As a account owner, I can check my balance online so that I can keep a daily balance 24 hours a day. Pretty easy right? As a account owner, I can check my balance online. Feel free to use slight deviations of this template using synonyms: As a [role], I want [feature] because [reason]As a [role], I can [feature]As a [role], I can [feature] so that [reason] 2. When creating new user stories, always hand write your new stories on a single side of a index card using a Sharpie marker. User stories are suppose to be short and sweet. P.S. 3.
