Re: Do you do Story Cards?
You can also try ScrumDesk (www.scrumdesk.com) - project management tool for teams using SCRUM.
- task board with story cards ( theme, tasks, progress tracking in chart)
- stories grid view
- drag and drop
- timeline (sprints, releases, demo)
- team management,
- product backlog
- planning releases and sprints with calculations (availability, occupation,...)
- tracking daily progress
- Next sprint view (stories from next sprint)
- retrospective (including voting for best ideas)
- SCRUM best practices metrics (velocity by releases, velocity by sprints including Worst Mean 3, Last Mean 8 calculation)
- teams are connected as a project-oriented social group
- changes notification
- teams can be distributed over the globe
- integration with bug tracking and project documentation systems
- easy call team member using IP call applications integration (Skype, NetMeeting, Microsoft Communicator,...)
- easy sending email to team member
Features for next release (will be released this or next week):
- story templates (if you have tasks that are always repeated in every story - unit test, deploy,....)
- few enhancements
--- In email@example.com, Patrick Wilson <piwilson@...> wrote:
> Another alternative to CardMeeting is a tool called AgilePlanner. I have
> (and currently still do) use AgilePlanner for distributed planning
> sessions. I find that Agile planner is much faster and more responsive
> for distributed changes than card planner. As well, it is Open Source
> (which is good).
> Mayank Gupta wrote:
> > CardMeeting is a cool idea. I tried it today and found it very
> > interesting.
> > I firmly believe that Information radiator is the key for co-located
> > teams. And the team should have their daily standup in front of
> > information radiator itself.
> > Regards,
> > Mayank
> > ------------------------------------------------------------------------
> > *From:* firstname.lastname@example.org
> > [mailto:email@example.com] *On Behalf Of *Desilets, Alain
> > *Sent:* Tuesday, March 25, 2008 7:53 PM
> > *To:* firstname.lastname@example.org
> > *Subject:* RE: [agile-usability] Do you do Story Cards?
> > William Petri wrote:
> > > I know some people like printed cards but I discourage them, as
> > people are much less likely to change a card by hand or create them on
> > the fly.
> > > Product planning should be a lightweight activity with broad
> > participation. The more elaborate your artifacts, the more inertia you
> > introduce
> > > into the process. That inertia limits agility.
> > Of course, for distributed teams, hard copies don't work. For those, I
> > find myself using CardMeeting a lot:
> > www.cardmeeting.com <http://www.cardmeeting.com>
> > Writing a cardmeeting card is not as quick and spontaneous as writing
> > on an actual cardboard card, but it's pretty close. And it preserves a
> > lot of the informality that seems to be good about paper cards.
> > Alain
newbie question - can anyone recommend some decent example Story Cards to look at. Some that I am seeing are very very deep techie based. Coming from a Cooper Goal-Directed Design background I'm used to scenarios which are very much rooted in the human world. Seeing deep techie story fragments which would be a microscopic part of a human scenario seems odd to me.Help appreciated.Carl
User Experience Design
- carl myhill wrote:
newbie question - can anyone recommend some decent example Story Cards to look at. Some that I am seeing are very very deep techie based. Coming from a Cooper Goal-Directed Design background I'm used to scenarios which are very much rooted in the human world. Seeing deep techie story fragments which would be a microscopic part of a human scenario seems odd to me.
Hi, Carl. It depends on what you mean by "deep techie".
I think any card should have a tag that a product manager can look at it and say, "yes, I see business value in that". And it's important to me that a team be able to instantly re-state a card in terms of why it matters to real people. So I think your desire to see things rooted in the human world is totally appropriate. I sometimes make my clients half-crazy insisting on it, but they eventually thank me for it. If sometimes grudgingly. :-)
My canonical bad tech-phrased story is
- create database schema
Except in certain very atypical projects, there is no reason a sane product manager would pay extra for this. It is not a shippable unit of work. It is not user visible. If it were possible to release without this card, you would. Ergo, it should be left on the floor, or done as a task, not a story. Instead, I like to see things in a subject-verb-object setup, where the subject is some user or user role. E.g.:
- Vendor logs in.
- Vendor submits invoice.
- Staff member approves invoice.
- Accounts payable clerk prints checks.
- Department manager reads monthly payments report.
The one time when I let people depart from user-focused phrasing is when I think they have it right in their heads, but use some other tag on the card. For example, the check-printing card above might be written as "ADP check-run integration". This is ok if (and only if) If I can ask any member of the team what that means and the can give me an answer in human terms like, "Oh, that's where George, the accounts payable clerk, kicks off a check printing run from ADP, our check printing vendor".
I think this is fine because although all work should be, in the final analysis, user-focused, describing every work unit purely in user terms can sometimes be awkward and faintly ridiculous. That's especially true for bug fix cards, cards that aggregate a bunch of little things, research cards, back-end processing, or minor tweaks to existing flows.
The only public list of real story cards I know of is this one that I posted last year:
Sorry for the poor formatting, but Yahoo's archiver mangled it a little. What you should be seeing is a list of cards broken down by week. E.g., the week of 1/1, they did two cards, a 2-point card and a 1-point card.
Most of the cards are in user terms (the ones starting with "User" and "Admin" mainly), but there are ones for back-end processing (the "Crawl" or "Crawler" cards), research ("Research"), and aggregation of little things (like "UI Cleanup"). And of course the release cards.
I hope that helps. If you need further info, don't hesitate to ask.