Re: User Stories Opinion
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.
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), but I also think the card system can work well as you suggest.
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) to keep things efficient.
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. It's a lot to handle.
In short, it's a long list of excuses, and the "verbal and card" model should work well if teams would take the time and energy to actually learn the skills needed. So, please don't take this as a criticism of the verbal and card model, just some reasons why many teams have difficulty with it.
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.