Should a technical communicator take part in estimating user stories?

For the convenience of writing in this blog, I need names for the two projects I'm working on. Let's call them Project Scissors and Project Stone.

It was time for a planning session on Project Scissors. I think this was an unusual case as the project was dealing with some new stuff that our team didn't fully understand. So, as part of this planning session the team wanted to estimate a series of user stories from the product backlog. To do this, they were going to use the planning poker technique. And they asked me to take part.

My question is:
Should a technical communicator be taking part in planning poker sessions?

A planning poker session would normally be used to estimate the product backlog and would happen before the sprints had started. In a planning poker session, everyone on the team listens to a description of the user story that needs to be estimated, and they all vote by using a pack of cards showing a number from the Fibonacci sequence.

Participants with high numbers or low numbers get the opportunity to discuss their reasoning with the team, and then another round is played. This carries on until a consensus is reached.

Developers get the chance to estimate testing tasks, and testers get the chance to estimate development tasks.

And then there was me. No one was estimating my user stories as I didn't have anything on the backlog - at that time.

So, was it OK for me to take part in the planning session?

My tactic (yes, I did have a tactic) was to never estimate lower than a 3 or higher than a 10. That left me with 3, 5, 8, and 10. My reasoning for this was I didn't want to have to justify my estimate to the team, and it made me 'fit in' with the team. Bit sad, but it worked.

But I clearly didn't contribute anything as I only understood about half of what was said in the room during the planning session, so in answer to my question - No, I shouldn't have taken part. I certainly didn't help the team reach an understanding of how large any user story was.

However, my inclusion did have a few benefits:

• I got the opportunity to listen to the user stories being explained. Yes, I might have had trouble understanding them, but then so did a lot of the team.
• I learnt more about the agile process.
• I got the opportunity to spend time with the team working towards a single goal. Some of the team are new to the business and up until that meeting, I really didn't feel like I knew them at all.

So, what do you think? Should technical authors take part in these estimating sessions?

End of first sprint

Last Wednesday marked the end of my first two week sprint on project A. What have I learnt?

• This isn't easy.
• I realised towards the end of the sprint, that I needed to get my work written as quickly as I was able so I could hand it over to the reviewer. It wasn't going to be acceptable to leave it until the last day.
• I have a good idea of what the team is working towards, and I haven't had to do any chasing to find this out; it's happened naturally by me being present in the daily stand-ups and planning meetings.
• I think the rest of the team have a greater understanding of the work that I do. For too long, there's been an expectation that user assistance will always be ready in time for the release. Now, the team can see my build this up over the course of the project.
• Not all project teams work in exactly the same way. Although the principles of Scrum are the same, how it's actually implemented is slightly different. There are different tools being used to track team progress, and even when the same tools are being used, they're using them in different ways.

TCUK - Beyond the comfort zone - Today you will not be writing a help file

In October, I was lucky enough to present at TCUK, the annual conference for technical communicators.

Here's the talk I gave about the need to step outside your comfort zone to help add value to your organisation.