Re: [scrumdevelopment] Re: User Stories Opinion
- User stories predate Mike Cohn's book by at least several years. They might predate XP as well (Many of the XP practices do) but I'm not sure about that. What Mike added to the conversation was the notion that Stories were a generally useful Agile concept that could be applied outside of XP (e.g. in Scrum.)Stories are misapplied by most Scrum teams that I encounter in principally two ways:1) There is confusion around the notion that "everything is a story." We still need to think about what is a story and what isn't, and many Scrum teams don't do this effectively (What XP actually meant by "everything is a story" is that we plan around stories. We don't plan around all the other stuff that we have to do that isn't a story.)2) They hyper-focus on the numbers (Mike Cohn's later book.) I see many Scrum teams, even ones that have been doing it for a few years, spend 70%+ of their time talking about estimates and reserving insufficient (in some cases no) time to have the conversation about what actually needs to be accomplished and how.
On Mon, Sep 27, 2010 at 10:08 AM, charles_bradley_scrum_coach <chuck-lists2@...> wrote:Ron,I will say this, though. I've met very few teams that can remember all of the logical details of a story without recording them so that they don't forget them. I suggested a whiteboard(and/or a pic of a whiteboard) for notes about a story, but I also think the card system can work well as you suggest.
Thanks so much for the great feedback. I agree with everything you said, and while I gave the impression that Cohn was the User Story "Man", I know he isn't the only one. I often use the 3 C's(With attribution to one of the foremost authors on XP, of course...) to back up my argument that a User Story requires all 3 components.
I also agree that no beginner should try to use everything in Cohn's book. I felt the same way about Cockburn's Use Case books and saw many teams missing the forest because they were so fascinated by the trees. Note that I'm not discounting Cohn or Cockburn, only backing up your point to keep it simple for beginners.
Having said that, I have experienced several reasons why the "verbal and card" model doesn't work out well for some teams. The biggest are:
#1. PO's whose availability to the team is limited. I see this time and time again, and it's really unfortunate. I try to coach my teams and their management that, especially for new teams, the PO position is a 100% full time position, and they should be directly co-located with the team. I try to stress that the first bottleneck of all Scrum teams is generally the PO(and by proxy, the ability of the organization to define product backlog items). Some companies just don't get it, though.
#2. PO's or other team members have enough trouble mastering the 3 C's, so when it comes to having the skills to slice stories small enough to fit on cards, based on best practices, these members usually fall off the train as well. They instinctively begin slicing stories horizontally across tiers instead of the more preferable way of doing vertical slicing. Not to mention that they sometimes start to call everything under the sun(dev tasks, time allocated for Scrum meetings, technical design, regression testing, defect fixing for user stories recently delivered!) a "User Story". It begins to morph a User Story into a set of tasks in a Work Breakdown structure(Project Plan)...it's a nightmare sometimes.
#3. The complexity of the business domain often gets in the way too. The requirements and business logic become so complex that they have to be documented somewhere. Again, I coach them to light documentations methods, and try to help them document in the more advanced forms of acceptance test styles(Spec by Example, Given/When/Then, Diagrams on whiteboards, etc)This is not a criticism of the "verbal and card" model at all, just some of the challenges I see when coaching teams. My viewpoint may be skewed in that the people that engage me are typically newbies or those that are having difficulty making Scrum work well. In the end, much of the time, it is impediments outside of Scrum that really get in the way of Scrum or User Stories working well.In addition to User Story skills, most of the teams I coach are trying to learn Scrum skills too, so learning the User Story best practices is yet another thing on their list of things to learn about and try to continue to do their jobs at the same time. It's a lot to handle.
In the end, I coach many teams to start out using a simple mechanism like a whiteboard, wiki, or even MS word to begin lightly documenting their stories. Then, once they're comfortable writing good stories with good acceptance tests, I coach them to begin slicing them smaller and smaller until many of the details and acceptance tests are less likely to be forgotten, and I encourage them to begin to "go verbal", first starting with smaller stories. Actually, usually about halfway through this progression, my contract ends, but I do hammer in the vision of going verbal. I don't know if what I'm doing is optimum, so I'd appreciate any feedback on this that anyone on the list might have.
An under-emphasis on requirements communication still seems to plague the software industry, and yet it is the cause for so much waste. Oh well, I guess that's job security for many of us.
--- In email@example.com, Ron Jeffries <ronjeffries@...> wrote:
>> Hello, charles_bradley_scrum_coach. On Saturday, September 25,> 2010, at 1:29:34 AM, you wrote:
> > First, based on my reading of Cohn's _User Stories Applied_, a User Story consists of:
> > 1. A title or description -- some folks use the formalized
> > version, but it's not required. (As a <user role>, I want
> > <feature>, so that <attain business value benefit>). I personally
> > think the formalized version is a useful tool but should really
> > only be used as a communication tool and every story need not be
> > formalized like that. A simple title will do.
> > 2. A conversation/collaboration between the PO and Scrum Team
> > 3. A set of acceptance tests to identify story success. (aka Conditions of Satisfaction)
> Um, yes. Or as someone put it long ago, a user story consists of ...
> The card is just a token used to pass around if one estimates, to
> hang on the wall as something to be done, to move around the status
> board, and so on.
> > Do I have that much right?Ok, then my opinion on that theme is:
> Yes ...
1. I believe the technique you describe is an estimation technique, and I don't think I'll change my mind on that. The minute you extrapolate your (historical)measurement in an effort to set customer/deadline expectations in the future, that's an estimate, IMO.
Here is a definition of estimate I found at reference.com:
1.to form an approximate judgment or opinion regarding the worth, amount, size, weight, etc., of; calculate approximately...
I also believe that when someone decides that a story is "small" or even "too big to fit within a sprint", that is an estimate as well.
2. What sent me 'round the bend was this comment from Steve:
> .I think that's why I'm starting to join the "don't estimate them" crowd.What I took that to mean was that stories are never estimated in any way, to which I replied I don't know any org that can do well without *some sort* of estimation process to set customer expectations. Steve might have meant "don't estimate them[Using planning poker and story points]". That's the reason I attempted to clarify, although my attempt at clarification might have been not so good.
> I don't know how any organization can execute well without some sort of estimation process in order to set customer/stakeholder expectations appropriately.When I used the term "estimation process" here, I was not speaking of story pointing or any other specific estimation technique, just that *some sort or type* of estimation technique is needed.
3. I see your technique as another estimation technique. To me, this is the real beauty of Scrum as a framework. The Scrum Guide says that backlog items are estimated, but it doesn't specify a particular technique for doing so. Your technique, IMO, is an estimation technique that was probably grown from the three pillars of Scrum theory: transparency, inspection, and adaptation. In my mind, it is just another candidate in the pool of other techniques that we discussed.
4. Though I've never used your technique(caveat), I think I could see some situations where it would work really well and some situations where it might not work so well. You've described some actual observed evidence of where it worked well and why. I respect that. The technique is highly attractive in my mind, especially for certain situations. Like all techniques, I'm sure it has its advantages and disadvantages in different contexts/situations. Thanks for throwing another handy tool in my toolbox.
I'll leave it at that for now. Thanks again for the excellent interchange of ideas.