Team activity/game for illustrating design in a SCRUM environment

Question

I'm looking for a team building / training activity for some of my scrum teams. I want something that really illustrates the flexibility that the team has when implementing stories to define the scope and complexity of the feature themselves. Most of the teams have long-term waterfall experience and are used to having a well-defined specification. I'm looking for something that illustrates the need for the team to vary the scope of what they are building themselves, dependent on the time and resources available.

I couldn't find anything at tastycupcakes.com and Google wasn't much help. Maybe someone has prepared something themselves they would care to share?

Edit (in response to request for example in comments)

Suppose the team has committed to building a story for displaying data to a user in a paged list for analysis purposes. The acceptance criteria can be fulfilled easily but a differnet implementation might provide added functionality e.g. wrapping a third party control which has built-in sorting and grouping functionality.

The point is, because the scrum time window is absolutely fixed the scope of the implementation may be pushed if the team feels they are ahead of schedule, especially if some technical designs proved less problematic than thought. Conversely, if some tasks have taken longer than anticipated, the team can short-cut the user story while still making sure what they delivers satisfies the acceptance criteria.

The thing I am trying to get away from is the current mindset that the feature has a specification set in stone, and that's what will be built, whatever the circumstances.

Answer 1

I don't think it is up to the team to define the scope and complexity of a story. It is the PO's job to define the conditions of acceptance and then it is the team's job to estimate size based on the PO's description. If the stories are right sized, the conditions are usually pretty tightly defined. This could be why you aren't seeing much out there ....

EDIT:

I don't think your example changes my answer. If the PO wanted this "additional functionality" such as sorting etc, they would have defined it in the story or in another story. To build something that isn't asked for is waste. Spending time on a story that is low priority in the backlog is inefficient. Agile is based on building what is needed and only what is needed in order of importance. So I would frown on developers adding "extra goodies" just because they are working on a particular screen.

That does not mean you shouldn't look over all the stories in the backlog and make architectural plans based on what will be needed in the future.

Answer 2

In order to estimate the story cost the team will be expecting to work with the PO to define, in at least broad terms, the requirements for that feature. In the example you gave the team may explicitly ask the PO if the sorting & grouping functionality is needed. If they say no, as the PO can't see a use for it at that stage, then the estimate is given on that basis and the implementation done according to that. No consideration is given to these additional features on the YAGNI principle. If the requirement for the sorting & grouping comes up subsequently as a result of people using early incarnations of the product, well, that's another story, and is estimated & scheduled into the backlog accordingly. The scope of the implementation of a story isn't changed just because you've got some time left in an iteration - instead you simply pull the next prioritised item from the backlog and get on with that.

Of course, when implementing the story the team are at liberty to use the most time/cost effective method that they consider suitable for the evolving product. If this means using an component with additional capability i.e. a superset of the features then they could do so (unless this is in breach of non-functional requirements), as long as the acceptance criteria are passed, but they shouldn't go deliberately adding in unrequested functionality just because they've got some time spare in an iteration.

Answer 3

My opinion is somewhere between your description of adapting the features to the time, which is left, and the "just fulfill the acceptance criteria and that's it" POV of the two other commentators...

In my point of view, you all should recall the formal setup of an user story:

As a -role- I want -feature-, so -aim-.

Given the purpose of a desired feature, the developer can better understand, what the PO really wants. He then can come up with additional ideas and ask the PO, e.g.:

Hey PO, if you want -aim- so why don't we do -alternative/addition to feature-. Wouldn't that be even better?

And the PO may agree and the story is implemented as described, but in another interpretation, or the story maybe adapted. The points that is important to me:

• The PO describes the purpose, he would like to have fulfilled, and a feature that is appropriate to do so
• The team does not just implement the acceptance criterias like development zombies, but they are open minded and are tuned to the PO's vision in general and the single story purpose in particular - so they may come up with additional/alternative ideas.
• The team also does not enhance user stories or over-engineer on their own authority. That's wasteful!

I hope you share my opinion ;-)

Answer 4

A good training exercise and a fun team building exercise is to do the XP Planning game.

The premise is that the product owner gives requirements for something visual (like a coffee machine, a robot) and all requirements must be drawable. The developers have to draw the requirements.

There are several short iterations (the whole exercise takes between an hour and 90 minutes depending on setup time) and it's interesting to see how communication improves and trade-offs happen as the game progresses. I've ran this myself during project kickoffs and when converting teams to agile practices and the team has always found it useful and fun.

Answer 5

I think I get what you're looking for, but feel free to clarify if I'm mistaken. I'm under the impression you're looking for an exercise that will show the flexibility in implementation details the team has when using user stories.

If so, try an exercise like this.

Split the team into two groups and have the same Product Owner between them (or you can have one Product Owner for each group if both PO's know the exercise).

The PO presents a fictional story like, "As an executive at BigSales Co, I want to be able to see, at a glance, which salespeople are performing and which are not, so that I can pair performers with under-performers to improve the overall team performance."

A story like the one above is light on implementation details, but has a very clear business problem to be solved (as user stories should). Using a story like this, give the teams 30 minutes to work on a paper prototype that would satisfy the user story. They can interact as much as they want with the PO during this time frame. The person playing the PO should be careful not to give them implementation details, but leave it to the team to decide, while expressing and clarifying the business need.

At the end of the 30 minutes, have each team present their solution and explain how it satisfies the user story.

The important thing here, is that once both teams have presented, it is likely that both presentations will be quite different and yet both valid. This shows the level of flexibility the team has to provide what they feel is the best solution without having to be told explicitly what to do.

Hope this helps.