AGILE IN ACTION

In his keynote, Jeff Patton reminded us to embrace uncertainty and asked if we've forgotten the meaning of iteration. Pascal has written about the keynote and has included some photos. Kerry Buckley also has a good write-up. Here's an extract:

Read our latest thinking on spikes.

Planning in detail too far into the future can be wasteful because changes will inevitably happen and they can't be predicted. The horizon of predictability marks the point where predictability moves into uncertainty. This horizon is the duration of an iteration. It's safe to plan in detail up to the horizon, but beyond it you should plan with a decreasing level of detail and precision. Adaptive planning defines a high-level plan or roadmap that contains the user stories to be developed over a distance such as a release, and creates a detailed plan for the next iteration only. User stories are well suited to adaptive planning because they're easy to use with different levels of precision. The figure below (adapted from James Shore 's Beyond Story Cards article) illustrates this effect. userstorycone Originally uploaded by sjb140470 . Beyond the current release, user stories are typically epics that focus on broad or vague features. During release planning, the selected user stories may be split into smaller user stories that focus on narrower features. However, the purpose of release planning is to quickly establish a sense of how big a release might be. It's not necessary to split the user stories too far. You can tolerate a larger inaccuracy in their estimates because changes will occur over the period of the release. As the user stories approach the next iteration, they should be split further to focus on progressively smaller and more specific functionality. As the user stories become smaller, they become easier to estimate and their estimates will become less inaccurate. By the time the user stories are planned into the next iteration you want them to take between 1 and 2 days to complete, as a rule of thumb. During an iteration, it's difficult to start developing the software for user stories when you only know their names. Recall the conversation element of a user story. The developers and the customer need to collaborate and talk about the details of a user story at the latest responsible moment, i.e. when the details become important. Typically this collaboration to reveal the fine details of the user stories begins in the iteration planning meeting and facilitates a translation of the user stories into acceptance tests. As part of the collaboration, it's important that the developers understand the benefits of, and the motivation for each user story. Rachel Davies suggests that the developers use a simple checklist: Do we understand the value to the business that this user story provides? Do we know who the beneficiary of the user story is? Have we defined all the acceptance tests? Next post in this series: User stories part 3: Using spikes to help estimate user stories Previous posts in this series: User stories part 1: What is a user story and who writes them? References: [1] Mike Cohn 's Agile Estimating and Planning [2] Kent Beck and Martin Fowler 's Planning Extreme Programming

What's a user story? A user story is a distinct unit of customer-visible functionality, which does not have to represent value to the business but must represent progress to the customer. It's meaningful to both the customer and the developers. Ron Jeffries uses 3 Cs to describe a user story: 1. Card: The name of the user story (no more than a word or two) used to facilitate collaboration between the customer and the developers. 2. Conversation: Collaboration and discussions that drill-down into the details of the desired functionality. 3. Confirmation: Acceptance tests capturing the details and used to determine when a user story is complete. Think of user stories as representing a collaboration between the customer and the developers, as opposed to documenting customer requirements. The purpose of this collaboration is to reveal and understand the details of the user stories, which are recorded in the confirmation. Some people write a short description of the user story on the index card, while others like a statement of the format: [Role] can [capability], so that [benefit] . I prefer Rachel Davies' suggestion, and put just the name of the user story on the index card. A verbose story card encourages people to think of them as requirements documents. A simple name, written in large capital letters, encourages collaboration that continues throughout the iteration William Wake advises us to INVEST in good user stories : 1. I ndependent: Dependencies between user stories should be avoided because they can lead to prioritisation and planning difficulties. 2. N egotiable: User stories are reminders to collaborate. Collaboration between the customer and the developers involves a negotiation to balance the desired functionality with the cost of implementing it. 3. V aluable to the customer: Whether a user story represents value to the business or simply conveys progress it must inherently be valuable to the customer. This enables the customer to intelligently prioritise user stories. Avoid user stories that have only technical value. 4. E stimatable: There are three reasons why user stories may not be estimatable: Developers lack domain knowledge. In this situation, collaborating with the customer will help them understand a user story. Developers do not possess the right technical knowledge. They should split the user story into a spike to gather information, and a user story to do the real work. A spike is an experiment that allows the developers to learn just enough about the technology to be able to estimate the user story. A spike must be time-boxed. This defines the maximum time that will be spent learning and fixes the estimate for the spike. A user story is too big. It should be split into smaller user stories during collaboration between the customer and developers. When development starts on a user story, it should take between one and two days to complete (including acceptance tests). 5. S mall: If user stories are too big they are difficult to estimate and cannot be planned into a single iteration. 6. T estable: User stories must be testable. A user story that passes all its acceptance tests (and all its unit tests) can be considered complete (subject to a final visual approval by the customer). Without this capability, developers will not know when they're done . Who writes the user stories? The customer writes the user stories because she's in the best position to know the desired functionality. Each user story must be written in the language of the business. This enables the customer to prioritise the user stories according to their value to the business and their cost, and select the user stories for each iteration. The developers can assist the customer but the responsibility for writing stories must reside with the customer. Next post in this series: User stories 2: Adaptive planning References: [1] Mike Cohn 's User Stories Applied For Agile Software Development [2] Kent Beck 's Extreme Programming Explained, Second Edition

When I first started using Extreme Programming I estimated user stories in ideal time . Later, when velocity replaced load factor , I switched to story points . A story point is a measure of magnitude. It's also a measure of the size of a user story relative to other user stories. Story points enable effort to be estimated without trying to estimate how long it will take. To derive an estimate for the duration of a project you divide the story points for all the user stories by the velocity of the development team (given by the number of story points completed in the last iteration). User stories can be estimated quickly using triangulation, e.g. I'm giving this story 2 points because it feels like it's twice as big as that 1-point story and about half as big as that 4-point story. I like the concept of story points , but I've seen development teams get confused by them and I've never met a customer who liked them. Why? Quite a few developers said something like: I get the idea but estimating with them doesn't feel natural . It's true that their abstract nature takes a little getting used to. For developers, the real confusion starts when a user story's tasks are estimated in ideal time . After a while, developers think they see a correlation between story points and time. They think, for example, that 1 story point = 4 ideal hours. An equivalence such as this isn't valid because a story point value actually corresponds to a distribution of time. A 1-point user story may take 4 ideal hours to complete, but it's also possible that another 1-point user story will take less, or indeed more than 4 ideal hours. To counter this variation in time and preserve equivalence, developers start to estimate in ideal time first and then convert to story points . When this happens the purpose of using story points is lost. Paraphrasing James Shore , the net effect is increased confusion about how to estimate, and a corresponding decline in the team's confidence and commitment to their iteration plans . Story points are equally unnatural for the customer, who's more used to getting estimates in time. I've often seen developers remind the customer that estimates are in story points and not time, to which the customer responds, Well what is it in time? This frustrates everyone and collaboration suffers because of it. The customer doesn't have an intimate relationship with the estimates like the developers do, so the estimates need to be easily understood. If the customer isn't comfortable with story points , he may not trust the estimates and that isn't good. The customer needs to trust the estimates because they reflect the cost of user stories, and he measures this against their value to the business in order to prioritise. I was interested to read that Chris Wheeler had experienced similar difficulties using story points , and James Shore reverted to using pair-hours because he realised that making estimating units more abstract made estimating and planning more confusing and difficult . Kent Beck also reverted to using time-based estimates in the second edition of Extreme Programming Edition Explained . Is this a trend? I'm not sure, but I'm switching back to ideal time too. I want to see whether the difficulties I encountered using story points go away. And I want to see what new difficulties emerge with ideal time . Reference: Mike Cohn's Agile Estimating and Planning

The process of breaking down a user story is important because it helps me think about how I'm going to build the functionality. Many people disaggregate a user story into tasks and then estimate them (usually in ideal time ) because they're smaller units of work and can be estimated with less inaccuracy. Then they total the task estimates to obtain a better indication of how long it will take to complete the user story. Tracking each task's remaining time feels like micro-management, so I don't it anymore. I'm only interested in tracking the number of running tested features . I want to know how many user stories are passing all their FIT tests. When I start developing a user story, I like to break it down into vertical slices of functionality that I note on the back of the story card. I try to define these slices in such a way that I can build them one after the other (refactoring in-between so they fit together with the latest extending its predecessor). It's similar to erecting a fence. This approach allows the customer to see and play with the evolving functionality and to provide feedback, which I take into the next vertical slice. As I work on a slice of functionality using test-driven development , any tasks identified are written down as notes on a piece of paper or an index card. This task-list is just an evolving to-do list for the slice. As a simple memory aid used in conjunction with test-driven development , it guides the way and reminds me of what I need to do. These tasks are very granular and because they're noted just-in-time they're not situated very far away, perhaps only minutes or tens-of-minutes away. Consequently, it doesn't matter where I write them because they'll be crossed-off soon enough when they're completed. It doesn't make sense to track the time remaining to complete one of these tasks because it's too small. Tracking running tested features focuses attention on the development team (and the user stories that they've committed to delivering) rather than on individual team members. Focusing on the team as a whole helps them to recognise their collective accountability and to develop their collective responsibility. This helps a team to become self-organising.