background preloader

INVEST in Good Stories

INVEST in Good Stories
(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. 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. Estimable Small Testable

Planning poker Planning poker, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates. The method was first defined and named by James Grenning[1] in 2002 and later popularized by Mike Cohn in the book Agile Estimating and Planning,[2] whose company trade marked the term. Process[edit] The reason[edit] The reason to use Planning poker is to avoid the influence of the other participants. Equipment[edit] Planning poker is based on a list of features to be delivered and several copies of a deck of numbered cards. Planning Poker card deck

User story History[edit] User stories originated with Extreme Programming (XP), whose first written description in 1998 only claimed that customers defined project scope "with user stories, which are like use cases". Rather than offered as a distinct practice, they were described as one of the "game pieces" used in the planning game. However, most of the further literature thrust around all the ways arguing that user stories are "unlike" use cases, in trying to answer in a more practical manner "how requirements are handled" in XP and more generally Agile projects. In 2001, Ron Jeffries proposed the well-known Three C's formula, i.e. A Card (or often a Post-it note) is a physical token giving tangible and durable form to what would otherwise only be an abstraction; The Confirmation, the more formal the better, ensures that the objectives the conversation revolved around have been reached finally. Creating user stories[edit] Format[edit] "As a <role>, I want <goal/desire> so that <benefit>" Run tests Or

Splitting User Stories Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The small requirement drives us to split large stories. But the stories after splitting still have to follow the model. Many new agile teams attempt to split stories by architectural layer: one story for the UI, another for the database, etc. This may satisfy small, but it fails at independent and valuable. Over my years with agile, I’ve discovered nine patterns for splitting user stories into good, smaller stories. (Note: As with any pattern language, I didn’t invent these patterns, I’ve just observed and compiled them. How Small? How small should stories be? When you’re in a planning meeting and you hit your trigger estimate, pull out the cheat sheet at the end of this article and try a few of the patterns until you find a good split. Which Pattern to Use You’ll often find that you can split a story using several of the patterns. Pattern #1: Workflow Steps Conclusion

Scrum Scrum is an iterative and incremental agile software development framework for managing product development. It defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal", challenges assumptions of the "traditional, sequential approach" to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called "requirements churn"), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. Later, Schwaber with others founded the Scrum Alliance and created the Certified Scrum Master programs and its derivatives. Each sprint is started by a planning meeting.

Agile management Agile management or agile project management is an iterative and incremental method of managing the design and build activities for engineering, information technology, and new product or service development projects in a highly flexible and interactive manner, for example agile software development. It requires capable individuals from the relevant business, with supplier and customer input.[citation needed] There are also links to lean techniques, Kanban (かんばん(看板)?) and Six Sigma.[1] Agile techniques are best used in small-scale projects or on elements of a wider program of work, or on projects that are too complex for the customer to understand and specify before testing prototypes.[2] Agile techniques may also be called extreme project management. It is a variant of iterative life cycle[1] where deliverables are submitted in stages. Agile Methods are mentioned in the Guide to the Project Management Body of Knowledge (PMBOK® Guide) under the Project Lifecycle definition:

IBM Rational Unified Process The Rational Unified Process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003.[1] RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process. History[edit] Combining the experience base of companies led to the articulation of six best practices for modern software engineering: Develop iteratively, with risk as the primary iteration driver[2]Manage requirementsEmploy a component-based architectureModel software visuallyContinuously verify qualityControl changes a tailorable process that guided developmenttools that automated the application of that processservices that accelerated adoption of both the process and the tools. RUP building blocks[edit]