That sounds much better!

 

I'm kind of with Bret that this seems like a low-value thing to be burning cycles on, but I have spare cycles today... :)

I like to use "token" to help explain user stories, because they are an abstract and incomplete representation of all that needs to be delivered (the value proposition, the capability needed to realize value, the feature -- functionality, user experience, technical, etc., the cost & risk). The user story is something we can toss on the table in front of us and say "Let's talk about this." So, I like token, especially in the context of "card."

For me, "ticket" doesn't quite work. This is getting pedantic, but to me a ticket is issued/sold by the holder of some capacity as a way to allocate that capacity to a customer. A user story is more of a purchase request by the customer. The ticket would be the capacity being offered (whether that's a slot in a kanban queue, or some number of points of velocity offered up per time period, etc.). A customer would procure some capacity and attach a purchase request (user story) to it to place an "order."

I know there is established use of the term "ticket" to mean a token of something being processed or built within some system, but I would still argue this use of ticket implies the order has been placed (request attached to capacity) and the resulting order is being tracked and called a "ticket." Once a story is actually accepted for delivery, it could be called a ticket within the team's system, I suppose -- when the card is pinned up on the board into an available slot, maybe it's now a ticket.

I guess I prefer to use the terms more like defined in dictionaries -- we agilistas have invented/redefined enough language.

Paul
-----
Paul Hodgetts -- Coach, Trainer, Consultant
Agile Logic -- www.agilelogic.com
Training, Coaching, Consulting -- Kanban/Lean/Agile/XP/Scrum
Deliver Better Software Faster -- We Can Help!

-----Original Message-----
1a. User Story Straw Poll
Posted by: "Mark Levison" mark@... marklevison
Date: Fri Dec 14, 2012 10:08 am ((PST))

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 <http://agilepainrelief.com/notesfromatooluser>
| Writing <http://agilepainrelief.com/notesfromatooluser/>
Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov
28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>
26 and Montreal <http://agilemontreal.ca/agile-tour-2012/> 24

On Sunday, December 16, 2012 at 1:43 PM, Charles Bradley - Professional Scrum Trainer and Coach wrote:

 

I think more context might help this thread.  This is the introduction of the term "card" in the article.

<snip>

• Card: A token (with a story title/description), used for planning and acting as a reminder to have conversations. The card is basically just a title or some descriptive text about the Story.  You can use a card, or some descriptive text, like a sentence, to represent a story as a token to remind you to have conversations about the Story.  It is a good practice to keep the title or descriptive text to as few words as possible.  The purpose of the card is to remind us to have  conversations.

</snip>

Bias alert:  In case it wasn't already known, I helped co-author this text, so I am probably biased.

Three main drawbacks with Ticket in my view:
1.  In our business, the term ticket implies an ALM tool "ticket", and I don't like implying that they need an ALM tool to do User Stories or Scrum.
2.  The term "token" is used in Ron's 3 C's article, as well as Ron's early work in Extreme Programming Installed.  As such, the language in this new article will be consistent with other credible literature on this subject.
3.  I don't think it brings much added understanding to the above snip, or the User Story practice as a whole.

Having said that, all of that other credible literature is written by the same guy who is now proposing a different term.  I don't think the "ticket" metaphor works as well when it comes to planning.  I also don't like the idea of an "...open invitation..."(attributed to Ron Jeffries, via CC license...), because an invitation strongly implies that it's totally ok if you don't come to the party.  In fact, after researching this further, I'm beginning to think that maybe instead of "reminder to have conversations" we should stick with Alistair's other statement about a User Story, that it is "a promise to have conversations."

For the people who think this thread is a waste of time, I'm ok with that.  OTOH, some of us, who have a lot of experience writing public articles/literature that are consumed widely in a complex industry, understand that some care towards choice of words has value.  I'm totally ok if you don't agree with that, but for the rest of you who want to help, please do so.  We "invite" you to a conversation, but it's just an invitation.  You don't have to come.  ;-)

-------
Charles Bradley
Scrum Coach-in-Chief
ScrumCrazy.com

---

From: Dave Smith <davewsmith@...>
To: scrumdevelopment@yahoogroups.com
Sent: Saturday, December 15, 2012 11:51 AM
Subject: Re: [scrumdevelopment] User Story Straw Poll

FWIW, I've always used 'placeholder', as in, "a story is a placeholder for a conversation." That's mostly what I hear, though I've heard 'token' on rare occassion, but never (or very, very rarely) 'ticket'. My clearest memory of 'placeholder' being used in conversation only goes back to 2004, though.

Dave

On Fri, Dec 14, 2012 at 4:10 PM, Ken 'classmaker' Ritchie <classmaker@...> wrote:

It is a "placeholder" too, isn't it?

Cheers,

--Ken ;-)

Ken 'classmaker' Ritchie (Atlanta, GA)

 

On Dec 14, 2012, at 14:28, Bret Wortman <bret.wortman@...> wrote:

 

Ha! Well, that makes sense. My $.02 is that either sounds equally representative of the concept.

On Fri, Dec 14, 2012 at 2:05 PM, Mark Levison <mark@...> wrote:

 

We're trying to put the finishing touches on a lightweight introduction conversations (aka User Stories) see: https://docs.google.com/document/d/1XPu6ODjh8x1wzm03SzaZ3nLBr0tiiWGkVX2lztGKsXk/edit (comments welcome). Ron says that he now prefers "ticket" over "token". My problem is my tiny little head grew up on "token". So I thought I would find out what was in wider use. Neither it would seem. As Bob S. pointed out we already have too many words :-)

Cheers

Mark

On Fri, Dec 14, 2012 at 1:15 PM, Bret Wortman <bret.wortman@...> wrote:

 

Resolving this dispute helps teams work faster and better ... how?

Seriously, though, I've never thought about what I call it. It's a user story, a card, a backlog item. Token or Ticket just seems like arguing about  whether my drapes are ivory or cream. We both know they're off-white....

On Fri, Dec 14, 2012 at 1: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

--

Bret Wortman

The Damascus Group

Fairfax, VA

http://bretwortman.com/

http://twitter.com/BretWortman

--
Cheers
Mark Levison

Agile Pain Relief Consulting | Writing
Proud Sponsor of Agile Tour Gatineau Ottawa Nov 28, Toronto 26 and Montreal 24

--

Bret Wortman

The Damascus Group

Fairfax, VA

http://bretwortman.com/

http://twitter.com/BretWortman

This makes much more sense now, Thank you all :)

~Yenni

--- In scrumdevelopment@yahoogroups.com, Michael Vizdos <mvizdos@...> wrote:
>
> With all that has been said about the bad points of keeping minutes during
> the daily scrum... Remember there are no scrum police and ultimately you
> and the team can do what you'd like.
>
> The opinions expressed here are written based on years of experience doing
> what you have proposed doing. Many of us have experience the badness that
> comes out of it.
>
> Here's the thing. It is our experience. Try it. Nobody is going to whip you
> with the Scrum whammy stick.
>
> Mike Vizdos
> On Dec 10, 2012 11:44 AM, "George Dinwiddie" <lists@...>
> wrote:
>
> > **
> >
> >
> > Yenni,
> >
> > On 12/7/12 3:34 PM, Yenni wrote:
> > > I'm not quite seeing why having minutes is such a bad thing. From my
> > > perspective it enables people to check back to it over the course of
> > > the day.
> > >
> > > There are plenty of times where items in the morning stand-up get
> > > mentioned and then need to be re-discussed later only to be forgotten
> > > about due to the fallibility of the human mind. Minutes give everyone
> > > the same information, that way only one person needs to be taking
> > > notes and can disseminate that information afterwards or post it on
> > > the wall.
> >
> > Having someone take minutes relieves everyone else of the responsibility
> > to pay attention and remember. By all means, take any notes you need for
> > yourself.
> >
> > If things are understood differently between people, that will show up
> > in the next day's standup. People will get better at making sure
> > everyone understands.
> >
> > Minutes may also discourage mentioning some issues, as the discussion
> > seems more official when someone is recording it. You don't record all
> > your conversations, do you? Think of the standup as a conversation among
> > the team members rather than a meeting.
> >
> > - George
> >
> > --
> > ----------------------------------------------------------
> > * George Dinwiddie * http://blog.gdinwiddie.com
> > Software Development http://www.idiacomputing.com
> > Consultant and Coach http://www.agilemaryland.org
> > ----------------------------------------------------------
> >
> >
> >
>

It is customary in these Yahoo Groups for new members to post an introduction. 
Here is mine:

I live in the Washington DC area, have been in the software development industry
25 years, originally a developer in C and Unix.  By the mid-90s I was doing
project management.  I came from the CMM disciplines and directly participated
getting CMM Level 2 and 3 for my organization.  I was certified by ASQ as a CSQE
and soon after got my PMP.  I got my CSM about a year ago, and planning on
taking the PMI-ACP in January.

One of the first lessons I learned about software development, even going back
to the late 1980s/early 1990s is that simply "throwing requirements over the
wall" wasn't a very solid way to ensure customer satisfaction.  I can only think
of one very minor outright failure of this method in my past, but can easily
remember several projects that didn't quite meet the mark.

Not being one who enjoyed failure, I analyzed the mistakes, reviewed the CMM
(this was before CMMI), the current PMBOK and our local processes and was
delighted to discover that pure waterfall was never enshrined in stone in any of
these methods.  Of course, I did enjoy the lively discussions with the quality
auditors who 'occasionally' approached this topic differently.

As I gained authority to try out modified approaches, we progressed to a more
liberal change approach, to greater use of prototyping, to test driven
development and eventually to a highly iterative approach sandwiched in an
architectural and project management wrapper that is essentially the FDD
(Feature Driven Development) approach.

Despite progressing towards Agile approaches even long before Agile was cool
(Like the country song, "I was Agile before Agile was cool.") I was a late-comer
to Scrum.  I found the evangelical fervor of the early Scrum disciples to be
off-putting, and frankly both a little naive (would you build a Navy procurement
system, or the IRS tax processing system, or a stock market system using pure
Scrum?) and also a little uniformed about the flexibility of both CMM and even
the early versions of PMBOK.

Lately, I have been heartened to see Scrum maturing to recognize that project
often need both a governance and an architectural foundation, and that end-users
(or Product Managers) are rarely the correct resources to provide this. 
(Consider the popularity of SOA, which is entirely architectural.  I will follow
up on this more later.)  I have not seen "Scrum of Scrums" work, but these
appear to be one answer to this issue.  Other answers would be to wrap a Scrum
into larger process like FDD.  (In fact, at this point, it's almost more of a
labeling exercise than adopting a methodology.)

So, there's my introduction.  Comments and feedback totally welcome.

-Dale

The real problem I have is that the ticket, token or item or invitation is not what it's about.

It is about the conversation this token represents. But I can't say, from the context whether the importance of this concept has already been introduced and the importance underlined.

I'd say that a token would work for me, but without your other points the importance of the specific concept falls flat for me.

I personally like the term reminder to have a conversation. It's already in the text. But in my opinion the 'reminder' the is more important than the token. The what vs the how so to say. It's important to be reminded to have the conversation, whether you do it with a token, ticket, post it, sticky, card or a ping pong ball doesn't really matter. This is what I meant with the fact that I didn't really care about the thing. The concern should be with the concept behind it. A reminder.

It might be argued that a token in itself is an abstract concept, but it can be misinterpreted as a poker chip, a piece out of a board game as well.

I agree on the possible negative association with ticket, which can even be a penalty or a violation.

I personally also still like the invitation. Of course it's not a strict agreement or contract, but if you show up late for a party, there might not be any champagne left. Same applies to the story. If you don't show up you might not get what you wanted. You might get nothing at all... You might be too late to stop the wedding. If you want to take part, you need to show up. And when you re the leader of the band, you might ruin the whole pay by not showing. If the importance of showing up is clearly explained, it should be of no concern whether the invitation is open or not.

I prefer invitation far above contact our agreement. They tend to shy away from any people aspect.

Jesse

Jesse

Welcome, Dale. I think you'll find this group quite interesting. Quoting Gene
Spafford's 1992 description of Usenet: "Usenet is like a herd of performing
elephants with diarrhea -- massive, difficult to redirect, awe-inspiring,
entertaining, and a source of mind-boggling amounts of excrement when you least
expect it."

Over the past 15 years I've been involved in building one of the largest trading
systems on the planet using basically an agile approach. No, it wasn't "pure"
Scrum, but it was more Scrum-like than not.

We conduct numerous SoS-like stand-ups during the week. Our service-oriented
architecture has allowed us to scale from a simple single-server
proof-of-concept to our current production system hosting 4 exchanges with close
to 1500 servers.

Mark


--- In scrumdevelopment@yahoogroups.com, "Dale" <dale_a_mcmillen@...> wrote:
>
> It is customary in these Yahoo Groups for new members to post an introduction.
Here is mine:
>
> I live in the Washington DC area, have been in the software development
industry 25 years, originally a developer in C and Unix.  By the mid-90s I was
doing project management.  I came from the CMM disciplines and directly
participated getting CMM Level 2 and 3 for my organization.  I was certified by
ASQ as a CSQE and soon after got my PMP.  I got my CSM about a year ago, and
planning on taking the PMI-ACP in January.
>
> One of the first lessons I learned about software development, even going back
to the late 1980s/early 1990s is that simply "throwing requirements over the
wall" wasn't a very solid way to ensure customer satisfaction.  I can only think
of one very minor outright failure of this method in my past, but can easily
remember several projects that didn't quite meet the mark.
>
> Not being one who enjoyed failure, I analyzed the mistakes, reviewed the CMM
(this was before CMMI), the current PMBOK and our local processes and was
delighted to discover that pure waterfall was never enshrined in stone in any of
these methods.  Of course, I did enjoy the lively discussions with the quality
auditors who 'occasionally' approached this topic differently.
>
> As I gained authority to try out modified approaches, we progressed to a more
liberal change approach, to greater use of prototyping, to test driven
development and eventually to a highly iterative approach sandwiched in an
architectural and project management wrapper that is essentially the FDD
(Feature Driven Development) approach.
>
> Despite progressing towards Agile approaches even long before Agile was cool
(Like the country song, "I was Agile before Agile was cool.") I was a late-comer
to Scrum.  I found the evangelical fervor of the early Scrum disciples to be
off-putting, and frankly both a little naive (would you build a Navy procurement
system, or the IRS tax processing system, or a stock market system using pure
Scrum?) and also a little uniformed about the flexibility of both CMM and even
the early versions of PMBOK.
>
> Lately, I have been heartened to see Scrum maturing to recognize that project
often need both a governance and an architectural foundation, and that end-users
(or Product Managers) are rarely the correct resources to provide this. 
(Consider the popularity of SOA, which is entirely architectural.  I will follow
up on this more later.)  I have not seen "Scrum of Scrums" work, but these
appear to be one answer to this issue.  Other answers would be to wrap a Scrum
into larger process like FDD.  (In fact, at this point, it's almost more of a
labeling exercise than adopting a methodology.)
>
> So, there's my introduction.  Comments and feedback totally welcome.
>
> -Dale
>

 

It is customary in these Yahoo Groups for new members to post an introduction. Here is mine:

I live in the Washington DC area, have been in the software development industry 25 years, originally a developer in C and Unix. By the mid-90s I was doing project management. I came from the CMM disciplines and directly participated getting CMM Level 2 and 3 for my organization. I was certified by ASQ as a CSQE and soon after got my PMP. I got my CSM about a year ago, and planning on taking the PMI-ACP in January.

One of the first lessons I learned about software development, even going back to the late 1980s/early 1990s is that simply "throwing requirements over the wall" wasn't a very solid way to ensure customer satisfaction. I can only think of one very minor outright failure of this method in my past, but can easily remember several projects that didn't quite meet the mark.

Not being one who enjoyed failure, I analyzed the mistakes, reviewed the CMM (this was before CMMI), the current PMBOK and our local processes and was delighted to discover that pure waterfall was never enshrined in stone in any of these methods. Of course, I did enjoy the lively discussions with the quality auditors who 'occasionally' approached this topic differently.

As I gained authority to try out modified approaches, we progressed to a more liberal change approach, to greater use of prototyping, to test driven development and eventually to a highly iterative approach sandwiched in an architectural and project management wrapper that is essentially the FDD (Feature Driven Development) approach.

Despite progressing towards Agile approaches even long before Agile was cool (Like the country song, "I was Agile before Agile was cool.") I was a late-comer to Scrum. I found the evangelical fervor of the early Scrum disciples to be off-putting, and frankly both a little naive (would you build a Navy procurement system, or the IRS tax processing system, or a stock market system using pure Scrum?) and also a little uniformed about the flexibility of both CMM and even the early versions of PMBOK.

Lately, I have been heartened to see Scrum maturing to recognize that project often need both a governance and an architectural foundation, and that end-users (or Product Managers) are rarely the correct resources to provide this. (Consider the popularity of SOA, which is entirely architectural. I will follow up on this more later.) I have not seen "Scrum of Scrums" work, but these appear to be one answer to this issue. Other answers would be to wrap a Scrum into larger process like FDD. (In fact, at this point, it's almost more of a labeling exercise than adopting a methodology.)

So, there's my introduction. Comments and feedback totally welcome.

-Dale

Mark,
It sounds like you and Ron are two team members in dispute.
How can this list help you resolve it?

Best wishes,
Avi

--- In scrumdevelopment@yahoogroups.com, 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 <http://agilepainrelief.com/notesfromatooluser>
>  | Writing <http://agilepainrelief.com/notesfromatooluser/>
> Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov
> 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>
>  26 and Montreal <http://agilemontreal.ca/agile-tour-2012/> 24
>

And yet.... in Geek#:

==========================
if ((!You.AreInConflict())||(You.JustWantSomeIdeas()==true))
{
   //
   // TODO:
   //
   // If you can't convey the meaning of "card" using words
   // maybe find a different medium that your audience will understand?
   // draw a picture, make an animation, tell a story etc.
   //
}
else
{
   this.post.Rollback();
   // maybe throw new IrrelevantAnswerException();
}


:)


--- In scrumdevelopment@yahoogroups.com, "avinap77" <avi.naparstek@...> wrote:
>
> Mark,
> It sounds like you and Ron are two team members in dispute.
> How can this list help you resolve it?
>
> Best wishes,
> Avi
>
> --- In scrumdevelopment@yahoogroups.com, 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 <http://agilepainrelief.com/notesfromatooluser>
> >  | Writing <http://agilepainrelief.com/notesfromatooluser/>
> > Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov
> > 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>
> >  26 and Montreal <http://agilemontreal.ca/agile-tour-2012/> 24
> >
>

... Or better yet, use what your team is already good at to flesh out a
solution, somethijng like this:

[Test]
public void ExplanationShouldBeUnderstoodByAudience()
{
   // arrange:
   Explanation e = new Explanation("card");
   Audience a = new Audience();

   // act:
   bool actual = a.Understands(e);

   // assert:
   bool expected = true;
   Assert.AreEqual(expected, actual);
}

Now fake it till you make it.

You could also extract an interface from Explanation and implement different
implementations for different audiences, but I'm sure Ron knows how to do this
refactoring already :)



--- In scrumdevelopment@yahoogroups.com, "avinap77" <avi.naparstek@...> wrote:
>
> And yet.... in Geek#:
>
> ==========================
> if ((!You.AreInConflict())||(You.JustWantSomeIdeas()==true))
> {
>   //
>   // TODO:
>   //
>   // If you can't convey the meaning of "card" using words
>   // maybe find a different medium that your audience will understand?
>   // draw a picture, make an animation, tell a story etc.
>   //
> }
> else
> {
>   this.post.Rollback();
>   // maybe throw new IrrelevantAnswerException();
> }
>
>
> :)
>
>
> --- In scrumdevelopment@yahoogroups.com, "avinap77" <avi.naparstek@> wrote:
> >
> > Mark,
> > It sounds like you and Ron are two team members in dispute.
> > How can this list help you resolve it?
> >
> > Best wishes,
> > Avi
> >
> > --- In scrumdevelopment@yahoogroups.com, 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
<http://agilepainrelief.com/notesfromatooluser>
> > >  | Writing <http://agilepainrelief.com/notesfromatooluser/>
> > > Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov
> > > 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>
> > >  26 and Montreal <http://agilemontreal.ca/agile-tour-2012/> 24
> > >
> >
>

I hope there will once be a programming language invented where "if (*
== true)" will result in a compiler error.

Best
Markus

On Mon, Dec 17, 2012 at 7:24 PM, avinap77 <avi.naparstek@...> wrote:
> And yet.... in Geek#:
>
> ==========================
> if ((!You.AreInConflict())||(You.JustWantSomeIdeas()==true))
> {
>   //
>   // TODO:
>   //
>   // If you can't convey the meaning of "card" using words
>   // maybe find a different medium that your audience will understand?
>   // draw a picture, make an animation, tell a story etc.
>   //
> }
> else
> {
>   this.post.Rollback();
>   // maybe throw new IrrelevantAnswerException();
> }
>
>
> :)
>
>
> --- In scrumdevelopment@yahoogroups.com, "avinap77" <avi.naparstek@...> wrote:
>>
>> Mark,
>> It sounds like you and Ron are two team members in dispute.
>> How can this list help you resolve it?
>>
>> Best wishes,
>> Avi
>>
>> --- In scrumdevelopment@yahoogroups.com, 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
<http://agilepainrelief.com/notesfromatooluser>
>> >  | Writing <http://agilepainrelief.com/notesfromatooluser/>
>> > Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov
>> > 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>
>> >  26 and Montreal <http://agilemontreal.ca/agile-tour-2012/> 24
>> >
>>
>
>
>
>
> ------------------------------------
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...! Groups Links
>
>
>



--
Dipl.-Inform. Markus Gärtner
Author of ATDD by Example - A Practical Guide to Acceptance
Test-Driven Development
http://www.shino.de/blog
http://www.mgaertne.de
http://www.it-agile.de
Twitter: @mgaertne

Charles, I just can't help myself here...

> some of us, who have a lot of experience writing public
> articles/literature that are consumed widely in a complex industry,
> understand that some care towards choice of words has value

Shouldn't //your specific// experience be telling you that, ummm...

"The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."

?

I assume this is also correct conveying information to an audience,

Or to quote Ron from a different recent thread:

> It turns out that minutes DO NOT give everyone the same information.
> Everyone interprets them differently

I guess the only thing you can be sure of is that no matter what wording you
choose, a large portion of your audience will misinterprate it.

All the best!
Avi

Yeah, I hear that is possible in most dynamic languages these days.
That's what makes scrum so powerful as a framework.

?!?!?

Thanks Mark for this extremely enjoyful thread!
:)


--- In scrumdevelopment@yahoogroups.com, Markus Gaertner <mgaertne@...> wrote:
>
> I hope there will once be a programming language invented where "if (*
> == true)" will result in a compiler error.
>
> Best
> Markus
>
> On Mon, Dec 17, 2012 at 7:24 PM, avinap77 <avi.naparstek@...> wrote:
> > And yet.... in Geek#:
> >
> > ==========================
> > if ((!You.AreInConflict())||(You.JustWantSomeIdeas()==true))
> > {
> >   //
> >   // TODO:
> >   //
> >   // If you can't convey the meaning of "card" using words
> >   // maybe find a different medium that your audience will understand?
> >   // draw a picture, make an animation, tell a story etc.
> >   //
> > }
> > else
> > {
> >   this.post.Rollback();
> >   // maybe throw new IrrelevantAnswerException();
> > }
> >
> >
> > :)
> >
> >
> > --- In scrumdevelopment@yahoogroups.com, "avinap77" <avi.naparstek@> wrote:
> >>
> >> Mark,
> >> It sounds like you and Ron are two team members in dispute.
> >> How can this list help you resolve it?
> >>
> >> Best wishes,
> >> Avi
> >>
> >> --- In scrumdevelopment@yahoogroups.com, 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
<http://agilepainrelief.com/notesfromatooluser>
> >> >  | Writing <http://agilepainrelief.com/notesfromatooluser/>
> >> > Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov
> >> > 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>
> >> >  26 and Montreal <http://agilemontreal.ca/agile-tour-2012/> 24
> >> >
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> > To Post a message, send it to:   scrumdevelopment@...
> > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...!
Groups Links
> >
> >
> >
>
>
>
> --
> Dipl.-Inform. Markus Gärtner
> Author of ATDD by Example - A Practical Guide to Acceptance
> Test-Driven Development
> http://www.shino.de/blog
> http://www.mgaertne.de
> http://www.it-agile.de
> Twitter: @mgaertne
>

 

And yet.... in Geek#:

==========================
if ((!You.AreInConflict())||(You.JustWantSomeIdeas()==true))
{
//
// TODO:
//
// If you can't convey the meaning of "card" using words
// maybe find a different medium that your audience will understand?
// draw a picture, make an animation, tell a story etc.
//
}
else
{
this.post.Rollback();
// maybe throw new IrrelevantAnswerException();
}

:)

--- In scrumdevelopment@yahoogroups.com, "avinap77" <avi.naparstek@...> wrote:
>
> Mark,
> It sounds like you and Ron are two team members in dispute.
> How can this list help you resolve it?
>
> Best wishes,
> Avi
>
> --- In scrumdevelopment@yahoogroups.com, 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 <http://agilepainrelief.com/notesfromatooluser>
> > | Writing <http://agilepainrelief.com/notesfromatooluser/>
> > Proud Sponsor of Agile Tour Gatineau Ottawa <http://goagiletour.ca/> Nov
> > 28, Toronto <http://www.torontoagilecommunity.org/display/PUBLIC/Home>
> > 26 and Montreal <http://agilemontreal.ca/agile-tour-2012/> 24
> >
>