I was wondering if anyone else has had a similar problem and how they solved it.

I feel pretty rubbish as he takes over the planning session, picks what we do from the backlog and too be honest I don’t really know what I’m doing in the meeting. Help me please, is this how it should work? What’s the point of me being in the meeting?

What Scrum says should Happen
This is why we have a Product Owner right? The Product Owner is the business representative in the team it’s the Product Owner’s responsibility to ensure they are engaging with the key stakeholders and and made the correct priorty calls in the best interest of the product. A key part of the Product Owner role is ensuring this vision is communicated back to the stakeholders.

Communicating the Product Owner’s Vision
In the past it’s not been uncommon for stakeholders to return to the office after a story workshop and realise they misunderstood the Product Owner’s vision. The team have wasted valuable time running a story workshop and starting the first sprint when it seems the senior stakeholders are not on the same page.

Yes, we’ve tried to get these stakeholders into the same room and have a high level discussion around the proposed project prior to starting the story workshop. However, when it is difficult to get these people into the same room (especially when it’s very senior stakeholders such as):

• Managing Director/CEO
• Sales Director
• Product Director
• CTO

The Product Owner has a tough (almost impossible job) to get these guys on the same page. Even when we have managed it we’ve only been able to get them together for 10 minutes or so, far less than is needed for a topic as important as this.

Communicating the vision through an Agile PID
To address this problem we introduced Project Initiation Documents into our Scrum process. Surprised? Well, it made sense, after all Agile is largely common sense and we felt this document would really add value and (hopefully) prevent misunderstandings. The main purpose of the document was to give stakeholders and (once signed off) the team a high-level insight into the project. The document would promote discussion from the senior stakeholders and help flush out any assumptions. The PID had a few very simple rules:

• The PID is:
• Authored by the Product Owner.
• No more than 3 pages (A4) long
• Approved by all stakeholders before the story workshop can take place
• Business focused and provides:
• Business Case
• High level overview of the features,
• ROI strategy through releases
• Risks
• Assumptions
• Potential Blockers

The Results Are In
We found Scrum with PID’s works and it actually works really well. The Product Owners found it wasn’t till they started writing the document that they really started thinking about their decisions. It’s a reflective process that before the PID they didn’t do enough of, by writing the PID they were constantly re-assessing their decisions and anticipating potential criticisms. The senior stakeholders liked it as they could read the document when they could give it their full attention it allowed them time to digest it, collect their thoughts in their own time prior to responding to all via email.

The document template forced Product Owners to tie their release strategy directly to ROI. This helped lessen waste by ensuring the proposed features had clear value. The document created lots of interest and generated the sort of conversation that was not present before. The team liked it as they had a well thought out product vision before the project’s story workshop had begun knowing the business case had been signed off by the senior stakeholders

For instance if in sprint 1 we commit to 20 points, but only actually make 15 points, then 5 points will be rolled over to the next sprint. The team will complete these 5 points in the following sprint and will get the credit for this and any other points they complete in sprint 2. So eventually the team will get their points and as sprint velocity is an average over many sprints it won’t make any difference to which sprint we get them in. So why all the fuss?

I’m working in a Scrum envrionment and I want to make visible the progres of my current sprint. Any clarification would be greatly appreciated.

Agile retrospectives are an important yet often neglected part of the Agile/Scrum process. Central to Agile is inspect and adapt – retrospectives are an important part of his. Agile promotes continuous improvement but this can only happen if teams take the time to look back and learn from their experiences.

When should Agile teams stop having retrospectives?

When Agile teams can no longer improve they can stop retrospectives. Seeing as this never happens, there will always be a need for retrospectives in Agile environments.

How do Agile retrospectives help ensure continuous improvement?

Action points are taken directly into the next iteration so the improvements identified are acted upon immediately and the team gets instant feedback – short feedback loops are important!

What is the ScrumMaster’s Role in Retrospectives?

In Scrum the ScrumMaster’s role during retrospectives is to facilitate the meeting. The team should be taking an active part in process improvement so you shouldn’t find the ScrumMaster taking all the retrospectives!

Agile Tip – Did you know?

Retrospective is derived from “retrospecatre” which means look back in Latin.

Who Should Attend?

In Agile anyone can attend a retrospective, however normally it is only pigs that are allowed to participate, chickens can only observe.

I’m trying to improve our Agile practices and I hear that Agile teams use Poker Planning during sprint planning but before I try and sell it to my team I’d like to hear from others on their experiences. I’m particularly interested in the key benefits it will bring and if they are any hints and tips for ScrumMasters when introducing this practice.

How important is continuous integration, and has anyone else come across similar reluctance from their teams?