I’ve worked on a couple of projects where we’ve got to the end of the iteration and realised that we don’t actually have anything tangible to show the product owner.

This tends to be because we’ve spent the majority of our time working on 'technical stories' which typically have no visible output.

This may be as a result of horizontal slicing of work rather than vertical slicing but what it essentially means is that the work you’ve done has no immediate value to anyone.

Sometimes there are technical aspects to a solution which have a lot of unknowns and combining those with a vertically sliced story would mean that the story becomes too big to fit in an iteration.

From my experience a way around this which has worked well before is to run a spike/experiment card where we work out all the technical details/gotchas and setup any necessary 'framework' and then have the other vertically sliced chunks of work plug into this.

Having said that I’m no expert in breaking down work into manageable chunks so if anyone has any other ideas I’d be interested in hearing about those.

The typical response if someone complains of being bored in a meeting or walks out of a meeting is that they should deal with it but that response doesn’t help us that much.

I think if people are bored then it’s an indication that the meeting isn’t particularly interactive/inclusive or that the person shouldn’t be in the meeting.

We can try to resolve that first point by having meetings which are designed more as a discussion/learning forum rather than a brain dump session by one person to the group.

This encourages more of a pull approach over a push one and seems to be more effective at keeping people’s attention as long as the topic of the discussion is actually relevant to them.

Frequently it seems that a more effective approach would be to have fewer people involved in a meeting and have one of the participants quickly summarise what happened for the rest of the team.