Working on multiple project teams

I've been asked by a colleague what my approach to attending meetings when working on multiple project teams and sprints.

This came up again at an end of project review where other team members are working on multiple projects at the same time. So, clearly in this age of scrum, this is a common problem for people.

One of the biggest problems with working across multiple sprint teams is that you spend more time in meetings. The more time you spend in meetings, the less time you obviously have to work in that sprint.

I've found this challenging. My default position was to attend all of the sprint related meetings for the two projects I worked on. This cost me 2 days out of 10. Effectively 20% of my working time was then spent in meetings.

As one of the projects neared its end phase, I dropped out of one project completely as I knew I just didn't have the capacity to do the work for both projects. Attending meetings for a project I wasn't working on, didn't make any sense.

Now, as one project has ended, and I've moved back to the other, those missed meetings have cost me a lot of understanding as to where the project is at. In essence, it feels very much like I'm back at square one with my work. The project's requirements have changed, and I'm finding that the work I've already done is out of date.

So, let's forget about that little blip. Let's assume I'm working on 2 projects again with similar deadlines. How am I going to approach my time?

What meetings do I consider important?

Very important

• Daily stand ups - Keeping in the loop is vital for sprint work. An efficiently run daily stand-up shouldn't make anyone would feel it was a waste of time.
• Sprint reviews - Get to see an overall picture of what the sprint achieved. 
• Detailed sprint planning - Get your tasks added to the backlog. If enough time is given between the high-level grooming and the detailed sprint planning, I don't see why tasks couldn't be emailed to the scrum master for them to include. This would get you out of this meeting as well. This depends on your role of course. If you're documenting like me, or testing, I don't see why you necessarily need to be present in the meeting itself - which often consists of developers hammering out the details of their approach.

Less important

• High level grooming - Again, depending on what role you have. User assistance is likely to be a secondary piece of work off the back of someone else's work, and is unlikely to be a user story in its own right. This changed for me towards the end of the project where I emailed the scum master to get 'finalising' activities added to the backlog, e.g. 'Finalise Installation Guide', 'Finalise Help system'.
• Retrospectives - Our teams distributed the results of the retrospective after the event, so I could catch up in my own time as to any actions. If I had a problem, I could email the scrum master outside of the retrospective.

I guess, it's always going to depend on what your role is, but I suggest that if people are feeling like they're spending too much time in sprint sessions then you should take a close look at the reasons why and try to address.