How many is too many?

The team has their first iteration ahead of them, and they will be working on several different tasks during the 4 weeks period. The tasks are picked out, the time estimates are done, the backlog is filled in, but now, since this is their first Sprint together, the team members have to start finding out answers to several questions they have before them.

LittleMissLisa believes that there are no absolute best answers, but that they have to come to what will work best for just them. The team may not discover it from their first attempt, but one has to start somewhere!

The Team is having a short brainstorming to solve the following:

Meaning – when describing a possible workflow for a task, how many and which statuses should they use for that?

The Team decided to have a coffee&chat break before each member writes on the post-its their suggestions – one post-it per proposed status.

The Alien: I have looked up “status”, and the meaning we are after here is “A situation or state of affairs.” What I found interesting is that plural of “status” is “status” in British English, and “statuses” in American English.

LittleMissLisa: We will be using AE plural to avoid confusion that might arise in communication because of such a simple thing as a plural form of a noun! Anyway, should we maybe write our ideas on the whiteboard?

The Team: Yes! Let us define what is important to have in mind when adopting our possible task statuses!

  1. CLARITY – They should be self explanatory.
  2. MODULARITY (WORKFLOW BUILDING BLOCKS) – We should be able to order them so that they correctly represent the workflow – in a time dependant sequence – like the Semaphore light states can be ordered in Red-Yellow-Green sequence.
  4. VISIBILITY – It would be good if we could divide the whiteboard in columns – a column per status, and organize tasks written on post-its within those columns, so that we keep the progress very visible at all times.
  5. A REASONABLE NUMBER – There should not be too few, but not too many statuses either. For example – DONE, NOT DONE may be a bit too few statuses. But, how many is too many?!


The post-its are written and the following statuses suggestions came up:

– Analysed
– Approved
– Assigned
– Cancelled
– Closed
– Duplicate
– Forwarded
– New
– Opened
– Postponed
– Rejected
– Resolved
– Submitted
– Verified

LittleMissLisa: Okay. So, we all agree that… let me see… 14 may not be what we here called “a reasonable number” ?

The Team: We agree!

LittleMissLisa: Okay. Maybe we can all together put all the post-its with the statuses on the whiteboard, and then try to move and group the similar ones together?

LittleMissLisa: This looks great! Can we maybe name the groups now?

The titles get put spontaneously, with the team members consulting each other around the whiteboard, in the same manner when they were moving and grouping and re-grouping the post-its.

The Team: This looks good! We can use these titles for our statuses! If a need to add or change something arises, we will do it. It would be silly to pretend we can figure out everything from the start.

The Alien: Hmmm, I heard about this old Waterfall methodology, when people honestly believed that they could figure it all from the start…

LittleMissLisa: It is not really that archaic. Not yet… that one and the clones of it are still used very much. The “Embrace change” wave works slower than many hoped it would.

The Alien: You humans are just too funny!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to FurlAdd to Newsvine


2 Responses to How many is too many?

  1. Eivind says:

    Nice work, Jelena. The grouping seems quite intuitive, but are we sure that it covers what we need? What about asking the team members about which scenarios or objectives they had in mind when coming up with their suggestions. Can these scenarios be successfully replayed with the reduced number of statuses?

  2. Jelena says:

    Thank you Eivind!

    In this particular case, we had a sunny day scenario, in a way, since all the members discussed the proposed statuses while moving them and grouping them together, and they came to a common solution that seemed okay.

    Let us say, it was not the case, and at the end of the grouping activity, we still have Toby who wants one extra status that everyone else seems reluctant to single out to a “basic building block” status.

    First step – Toby should try to explain the scenario where he thought an extra status he proposed would bring in an extra value to the process of describing the workflow, and to the people working with it.

    If the group still does not change their opinion after their attempt to understand and the discussion, the coach/facilitator could help with making it clear that different people have very different abilities to understand abstractions fast, but quite similar and approximately equally fast understanding of an obvious need if they personally encounter it. Abstractions are hard.

    Also, the group does not work with crystal balls and similar, trying to predict everything from the start – no; they will happily change their ways if that brings them progress.

    In that case, if the group still thinks that the status Toby proposed should not be singled out, hopefully everyone, including Toby, will agree that it should be simple to just add a new status if the need occurs.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: