Re: [scrumdevelopment] User Story Straw Poll
- While to some, this must be really important to get right... I don't really see the significant difference between the two. If you use a piece of paper, call it a ticket... if it's on a block of wood, call it a token... If it's made out of lego's... really...It is important that the story is small and concise and fits on a card, piece of paper, something with a limitation to force you to focus and to split when needed... I'd call it: Card, Sticky, Work Item (for the TFS users)... but rarely a token nor a ticket.On Fri, Dec 14, 2012 at 7:08 PM, Mark Levison <mark@...> wrote:
This a simple non-binding poll that I'm using to try and discover general parlance.Ron and I are currently debating the use of Token vs Ticket in the context of User Stories.I've grown up thinking that the Card portion of a User Story was:
Card: A token (with a story title/description), used for planning and acting as a reminder to have conversations.Ron - says that "token" should be replaced by "ticket" because those are the magical words originally invoked by Alistair 14 yrs ago. (14 yrs ago I was just trying to wrap my head around UseCases but I digress).Which do you use?Cheers
Mark - a human
Agile Pain Relief Consulting | Writing
Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24
- LOL! Love it! Thanks for the clarifications. A lot more clearer to me now what you were getting at. Thanks for taking the time to reply :)-kOn Dec 20, 2012, at 9:01 AM, avinap77 wrote:
I have a real sweet spot for linguistics so...
--- Kevin Callahan <kcallahan@...> wrote:
> when we create artifacts, we can either just throw them together, or > we can take some time to actually make sure they are crafted in such > a way that they convey some degree of intent.
There must be other options in between, although I prefer some degree of crafting to convey intent.
//Some// being the keyword - I doubt if pinpointing "ticket" or "token" is really what helps convey the intent of a "card". It also depends on your audience - people who already use cards effectively don't really need the fine-detail definition. People who don't use it probably won't learn how to use it by defining it as either "token" or "ticket". They will each take their own subjective definitin of "ticket" or "token" and assume card" means the same. So are we going to now try and define what a "token" is or what a "ticket" is? that would be futile.
Have you tried to teach an infant what "cat" means? It won't work by giving verbal pinpoint definitins ("a cat is an animal with a tail and two pointy ears. It's of the Feline family etc etc"). They learn what "can" means by shoing them a cat, a picture of a cat, a movie, by making a meyaow, by telling them a story about a cat etc. They learn the meaning of the word by cross-referencing it with other experiences. To be percise, they learn //how to use the word effectively// by relating to other experiences and examples. (If they are taught or mistakenly deduce that "cat" is something you kick, and will later be cat-kickers, their use of the word will be ethically negative, yet semantically correct to their own semantic definition).
So back to card/ticket/token - I believe the best way to convey the meaning of card - or betteer, the way to effectively use that term - is by example, by stories, etc. I remember Ron and Chet (or was it only Ron? I don't recall) once had a nice series of stories demonstrating agile development (it was about some servant-leader manager, I forget the percise name although the experience will never leave my mind). That was an excellent way to convey meaning. And like I just realized - the exact terms and details have now totally escaped me, so maybe they didn't really matter.
Like Wittgenstein said (Oh and if he said it it //must// be right, eh? :)) - words are like a ladder. Their intent is to get us over the wall, but once we're there we can throw away the ladder.
> As for Ron's point, absolutely, which is why I believe developing a
> somewhat standardized/ubiquitous language is of value. If there is
> collective alignment through conversation about the definition of
> specific words and terms, it frees up a lot of bandwidth to actually
> getting to the value, rather than spinning wheels talking about it.
Again I agree - using standarized vocabulary frees us and gets us more productive.
Like happened with AJAX in web development - we all did AJAX long before the term was coined, we just didn't call it that. But just coining the term wasn't enough to free us - in fact, most peole these days use the rerm and probably don't eaven know what the accronym stands for. (quick quiz - do you?).
The big "boom" of AJAX happened when people and organizations started building "magical" AJAX frameworks (when Microsoft was callig it Atlas there were already a great many open-source frameworks out there, this all long before JQUERY became a standard).
Only once people could easily USE ajax frameworks did it become common knowledge, and it could become a term that people(=developers) can use to communicate and free themselves to effectively make super-califrajalistic-fast-web2.0-smartclient-whatever-is-a-fad-these-days-websites.
So coining "card" into a common understanding isn't going to happen because we pick the right word for it (ticket/token/anything else) but by people using it effectively. And yes, there will always be differences in nuance between the way different people use the term. That's what makes us human. That's what makes us capable of creating new terms. And Like the Big Ball Of Mud - somehow it just works.
All the best!
I hope I managed to convey //my// meaning effectively