Tweaking a working team

Posted: March 4, 2014 in Scrum
Tags: , , ,

One of my three teams works mainly on a communications engine and provides a lot of operational support for new reports and static information, particularly around this time of the year. They’ve run Scrum without a Scrum Master for almost a year and have managed to keep things ticking over. After observing for one sprint (three weeks), I facilitated the following minor tweaks based on my observations:

  1. Sprints now have an overarching sprint goal that the team can swarm around where necessary. I find a sprint goal is a simple and useful tool for helping teams maintain focus and make good decisions. We agree on the goal with the Product Owner during Sprint Planning I. I know some advocate that the goal be agreed before planning and possibly even as early as at the Sprint Review for the previous sprint, however in our world where we don’t really have a product, it’s easier to do it together with the sprint commitment. The goal conversation has also already helped us during Planning I where the Product Owner had to re-prioritise based on the fact that we couldn’t achieve all the goals with the team capacity available, so he had to make a call on which goal was the most important goal. Having a goal also led to some of our developers volunteering to support some testing work by creating tools to ease data comparisons. This reduced the manual effort required significantly, leading to us achieving far more in a sprint than we otherwise would have.
  2. Defined our Definition of Done (DoD) which is now posted up on the board. For me the most useful part of doing this DoD was the exercise itself (see below) as it helped me better understand the release and testing cycles. For this team, most of the tasks are done at a story level and there was no work required at sprint boundaries to complete their DoD. The challenge across all teams within our IT department is that the first fully integrated testing environment is UAT, and this environment is only updated/available prior to major releases (which happen approx. every 9 weeks). This impediment is one which will need addressing over time and is on the Scrum Master forum’s radar.
  3. Revived the practice of acceptance criteria for stories. The team opted to have these written on the back of their story cards. In this team, the most valuable aspect of having acceptance criteria is the conversation required to identify them.

Useful tools / links:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s