User Stories Opinion
- Hello all,
I'm new to user stories and I would like to run some examples and questions by the group. For my next project, I'm trying to get away from typical requirements and start moving towards user stories, which I have never used. Here's a brief overview of the project.
* Create three panels (or screens) for a content management system that allows users to add, edit, and search for articles, images and sections for a web site.
* Articles and Sections will include workflow such as Save, Publish, Schedule to Publish, and Unpublish. Images will only include Save functionality.
Let's just consider the Add and Edit Article panels for a moment. The Add Article panel includes 28 fields, 15 of which are required. The Edit Article includes 30 fields, 15 of which are required. The fields can be logically broken down into 7 groupings (e.g. Assets, Meta Data, Date/Time, etc.) if desired. However, in the end, all of the fields will be necessary to publish an article. Front-end design/HTML work plus back-end database work will be required.
That's pretty much it in a nutshell. I know how to create standard requirements for this, but here's a stab at some user stories...
1) "A CMS user can post an article to the web site."
Given the amount of work that needs to be done, this story is too large.
So I could break them down like this for example:
1) "A CMS user can add and save article date/time data including article date, article time, and update date."
Note on card: "Danielle says Article Date and Time are required fields for publishing, but not saving. Additionally, Update Date only appears on the Edit Article panel."
Back of card: Try saving article with a two digit month, day and year.
My Questions: What if the current date and time were included as default values? Where does that info go? Should Update Date be included since it only appears on the Edit Article Panel?
2) "A CMS user can add and save article asset data including related images, products and a slideshow."
Note on card: "Reese says an image is required for publishing, but not saving."
Back of card: Try saving article with a very large image.
My Question: What if the images must be a certain length and width and cannot be over a certain file size?
3) "A CMS user can add and save article meta data including meta description and keywords."
Note on card: "Matt says a meta description is required for publishing, but not saving."
Back of card: Try saving article with a very long meta description.
My Question: Let's say the max description should be 100 characters and commas should be used to delimit keywords. Where should that info go?
I would follow this pattern until all of the fields are accounted for. I can also create a user story for search. Another for each portion of workflow, but that seems a bit tricky because of specific details and exceptions that may need to be captured.
Am I on the right track? Any advice, tips, suggestions? Any help would be appreciated.
> > 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.