background preloader

INVEST in Good Stories, and SMART Tasks

INVEST in Good Stories, and SMART Tasks
(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. We don't expect customers or users to view the system the same way that programmers do; stories act as a pidgin language where both sides can agree enough to work together effectively. 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. Negotiable… and Negotiated A good story is negotiable. Valuable A story needs to be valuable. Small

Related:  Agilidad, Lean y KanbanUser StoriesSCRUMAgile - Lean - Kanban

Why I still use use cases XP pretty much banned use cases, replacing them with the similar sounding “user stories” (see A user story is to a use case as a gazelle is to a gazebo (discussion: Re: A user story is to a use case as a gazelle is to a gazebo)}, and as a result agile zealots have been happy to dump use cases in the trash (along with their project managers, estimates, plans, and architectures). Scrum did similar, using the “product backlog” instead of user stories. Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems: User stories and backlog items don’t give the designers a context to work from – when is the user doing this, and what is the context of their operation, what is their larger goal at this moment? Use cases are, indeed, heavier and more difficult than either user stories or backlog items, but they bring value for that extra weight.

Six attributes of good user stories One of the things that many agilists struggle with, particularly in the beginning, is what constitutes a “good” story. Many people start out with the familiar agile format of “as a user, I want to do this, for that reason,” but quickly find themselves running into issues of finding the right story size, complexity, scope, and various other factors. Fortunately, experience has provided a good framework for managing these issues. Mike Cohn specifies six fundamental attributes of a good user story in his book User Stories Applied. These are (1) independent, (2) negotiable, (3) valuable to users or customers/purchasers, (4) estimatable, (5) small, and (6) testable. For the sake of planning and prioritization, stories should not be dependent on one another.

Suggested Topics for Definition of Done Discussion Ken Schwaber and the rest of us advocate paying attention to what “done” means for a Product Backlog Item (PBIs, or “stories”). For a lot of programmers (like me), “done” often means “It works on my workstation!” The Scrum Master is charged with advocating a “done” that includes everything else needed to build a potentially-shippable product increment. So we need a cross-functional team. To avoid nasty surprises at the Sprint Review Meeting, I’d suggest initially attaching a definition of done to each PBI during the estimation process. Don’t be surprised if the estimate more than doubles — better to find out now than have the illusion of progress and an unpredictable ship date.

7 Obstacles to Enterprise Agility Print version I work with divisions of large companies that are struggling to become agile, starting with Scrum. While each organization is in a distinct business sector using different technology and management cultures, each one shares a common pathology, a kind of “giantism.” This article lists common obstacles to agility in large organizations and explores the possibility that the symptoms of giantism are entirely avoidable. At first glance, an organization’s challenges will appear to be “too much to do” or “not enough resources” or “changing business climate.”

Scrum 3.0 and Organization 4.0 - impressions from a great evening with Boris Gloger at ImmobilienScout24 Today I had the opportunity to join a great and inspiring presentation by Boris Gloger talking about Scrum 3.0 and organization 4.0 (thanks to Immobilienscout24 for hosting a great event). With this post I provide a short summary of my notes and insights and links to further posts I already wrote about some topics presented today. Based on an initial blog post by Boris (DE) - we started today with a recap of the Scrum journey from Scrum 1.0, Scrum 2.0 and developed to today's Scrum status. Scrum 1.0 foundation by e.g. 2 Days hands-on Training/Workshop on Agile User Stories by Naresh Jain - Expert Agile, Scrum, eXtreme Programming and Lean Startup Trainer and Coach in India The User Story Workshop offers a comprehensive, hands-on introduction to authoring high quality user stories combining techniques from eXtreme Programming and User Centred Design (CDP). User Stories helps us manage requirements. Their primary job is to define the value a user gains from the system. Since User Stories focus on the underlying Agile values of collaboration and Just-In-Time definition, it makes them a good Agile tool. User Stories are small narrative texts (2-3 sentences) in everyday/business language of the end user of a system. These capture what the user does, or needs to do as a part of his/her job function.

Scrum Reference Card Print version A Management Framework Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each. It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework. What powerful questions does Scrum help you answer? The video on powerful questions made me think about the deeper purpose of the various Scrum activities. Can I formulate Scrum as a series of Powerful Questions to be general enough, that they might be useful outside of software development? Here is the image I came up with and below are the questions I think each of the Scrum Activities and artefacts strives to help you answer.

INVEST (mnemonic) One of the characteristics of Agile Methodologies such as Scrum or XP is the ability to move stories around, taking into account their relative priority - for example - without much effort. If you find user stories that are tightly dependent, a good idea might be to combine them into a single user story. The only thing that is fixed and set in stone in an agile project is an iteration backlog (and, even then, it can be broken). SAP HANA SPS 11: New Developer Features In this blog, we will collect the various smaller blogs that detail all the new developer related features in SAP HANA SPS 11. This will be a "living" document which is updated as new blogs are released. In this blog series we are going to describe a large number of new features in both the underlying HANA infrastructure and in particular in the custom development aspects of HANA native development.

LeanEssays: Friction One third of the fuel that goes into a car is spent overcoming friction. By comparison, an electric car loses half as much energy - one sixth - to friction. Who knew electric cars had such an advantage? Friction is the force that resists motion when the surface of one object comes into contact with the surface of another. You can imagine parts moving against one another in cars, but do you ever wonder what happens when your products and services come in contact with customers? Might this create some friction? Getting Value out of Agile Retrospectives Hi guys, I want to use this post to introduce a topic I will discuss during next few weeks. Me and my colleague Ben Linders we are writing a pocket book about agile retrospectives. The title of this book is: “Getting Value out of Agile Retrospectives“. The main target are: Agile coaches, scrum masters, project or product managers or facilitators who have at least some experience with doing agile retrospectives. They know the purpose of them, how they fit into agile / scrum, and how to arrange and perform them.