Tag Archive: sprint


I was recently thinking about a definition of ‘self-organising teams’.I quickly came to the conclusion that collecting examples of self-organising behaviour was the best means to help this process.

My team approached me because they were confused about how we calculated Capacity for a Sprint. The team had two new members and I was reducing their capacity down to 50% and therefore the number of hours that were available for project work by the same amount. @phil_12d3 (Twitter tag) pointed out that this made no sense as everybody was at work for the same amount of time. The result of the variance I added, was that the newer members of the team ended up filling up their time with Support work. My attempt to measure and estimate personal capacity for the Sprint was flawed. We worked through a few new ideas as a team to find a better and more accurate way to estimate the number of productive hours available.

Phil eventually honed the rough calculations we made on a white board to the infographic below:

 

 

 

 

 

 

 

 

 

 

 

 

 

Creative Commons License
All work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

The hours are broken down between Project work, Support time, Meetings and Study time per developer. This made for a far simpler calculation.The variance in how long different tasks would take, was applied via a modifier during the final phase of Task Estimation. I was slightly uncomfortable with the necessity of allocating tasks per team member at the beginning of the Sprint. The preferred route would be a fully multi-disciplinary team that chose which tasks were worked on a voluntary and priority basis. My intial misgivings were overcome by the enthusiasm of team members over the ability to measure capacity and thus delivery on a daily basis.

To return to my original point; the process we went through as a team to develop this crucial process is an excellent example of a self-organising team. The team was not only focused on delivery but also the mechanism to improve the estimation and process of the Sprint.

Can you identify examples of self-organisation within your teams?

I previously wrote about the benefits major marketing agencies were experiencing by implementing Agile techniques within their business. Taking that concept one stage further I’ve re-engineered Mike Cohn’s ubiquitous Scrum framework diagram to show how Teehan and Lax’s six steps to Adaptive Marketing can be applied to this process.
Mike Cohn’s Scrum Framework Copyright 2005 Mountain Goat Software
Adaptive Marketing Using The Scrum Framework  – Diagram
Creative Commons License
All work is licensed under a Creative Commons Attribution-NoDerivs 3.0 Unported License.

The Six Steps are as follows:

1.     Product Backlog

The agency and client define the objectives of the engagement and establish several key performance indicators. The first step is all bout establishing the vision with the client and producing a product backlog with the team.

2.     Sprint

The creative team is dedicated to the project for a set period of time allowing them to focus on the task. Creating the Sprint is a familiar concept to Agilists and it makes perfect sense in the context of a marketing campaign.

3-5.     Meetings

Steps 3 -5 are encompassed in the Empirical framework of Scrum. Ideas are rapidly developed, tested and deployed
Ideas evolve and adapt over time. Performance is closely monitored allowing the team to make adjustments.

The combination of Sprint Planning, Daily Meetings, Sprint Review and Sprint Retrospectives all support an inspect and adapt approach to marketing.

6. Sprint Review and Retrospective

Project success is determined by achieving the KPIs. The Sprint Review meeting covers the necessary KPI’s to ensure that all activities match a state of ‘done’ and whether the process and campaign were successful.

Using the Scrum Framework gives transparency to the Adaptive Marketing process, a corner-stone of the Agile approach.

Do you practice Adaptive Marketing or have you implemented Agile at Enterprise level? Have you used the Scrum Framework outside of Software Development? How did it go?

I’ve blogged before on the role of being a designer in a Scrum Team. I thought it would be interesting to micro-blog my actual experiences of participating in the Sprint.

Day 1
First day of being back in the Sprint with the developers. I’m feeling the subtle pressure (or is that motivation?) to get my tasks done on time. We are working on a high-profile project and I can’t afford to hold up development by not having the design work completed.

Day 2
The wireframes have been created but the layouts are all wrong, so I need to pull my finger out! The 960.gs CSS framework is a great help in the creation of the wireframes.

Day 3
I forgot to update my tasks before I left last night. Consequently we are behind on our Burndown Chart. I have to confess to the team that I didn’t practice what I preach. A humbling experience and I will definitely remember tonight and also cut some slack to my team in the future if this happens on the odd occasion.

Day 4
Chris Brogan recently said that “doing is more fun than planning”. Turns out he’s right. I’m enjoying keeping track of my tasks and having the opportunity to move my post-its across the board to ‘Done’. I think if you haven’t been in the Scrum you are losing a vital perspective on how the Sprint dynamic encourages a feeling of success.

Day 5
The post-its that have been bought from a local supermarket keep falling off the board. I had heard the team mentioning this, but hadn’t completed appreciated how annoying it is. The next purchase of post-it’s will be the genuine thing.

Day 6
I’ve cheated and added some additional screens to an existing task. I can’t decide whether this is utilising Scrum in a flexible way or I’m committing a Scrum sin. I’ll pick up the issue in the retrospective with the team.

Day 7
The Sprint has blipped. We have a developer unexpectedly out for two days. That’s a lot of ground to make up and we may need to take something out of the Sprint to compensate.

Day 8
In the Pre- Sprint Planning Meeting with our Product Owner we discussed a new design for a Blog Template. I promptly forgot to include that in the task so now I have to make up the time. In this situation wireframes are a great solution. Wireframes provide the developers with the information they need to get going whilst buying some time to complete the design.

Day 9
Being more physically involved in the Sprint has made me realise that the whiteboard could do with an overhaul. The board should be at the centre of the team, radiating information out to the wider business.

Day 10
I’ve gained final approval the last of my design work so my active tasks in the Sprint are set to Done. I’m back to the role of Scrum Master but I’ve learned a lot and been reminded of how it feels to be ‘in the Sprint’.

Day 11
I was reading ‘Agile Coaching’  and came across the following link:
http://www.xqa.com.ar/visualmanagement/2009/02/visual-management-for-agile-teams/
Combined with my recent interest in visual thinking, this opened my mind to the possibilities of expanding the purpose of the current whiteboard. The current board is simply a ‘task board’ and there is a clear opportunity to make it a ‘team board’.  We are shortly transitioning to VS 2010 Agile 5.0 templates. After that change has been completed I’ll talk to the team about shaking up the whiteboard.

Day 12
It’s the last day of the Sprint and we managed to bring it in on-time. This is a great achievement as we lost some resource and velocity mid-sprint. I will be including my work in future Sprints, as it’s been a great reality check.

Are you a designer in a Scrum Team? Should design work be included in the Sprint? Let me know what you think.

Somewhere over the rainbow

Well worth watching this, it’s only 20 minutes:
http://blog.ted.com/2009/08/the_surprising.php
I recently watched one of the very good TED talks (see link above – I’d highly recommend you take a look at these). The talk was about the surprising truth that incentives, rewards and bonuses do not motivate teams to perform better. At best they encourage a plateau of performance, at worst they drive performance down. There’s a great comparison at the end involving Microsoft.


The primary message I took from the talk was that we need to find alternative ways to motivate our teams. In consultation with senior management we decided to institute an informal implementation of Blue Sky days.

The Blue Sky days concept is simple; empower people to spend time doing what they enjoy and allow them to investigate new technologies or ideas that might ultimately deliver innovative solutions to problems or products. A defining feature of the scheme is that it is driven by the individual or team and it’s hands-off by management. The same idea is employed by Google and has generated the energy and enthusiasm in many Google projects including Maps and Wave. Blue Sky Days are awarded at the discretion of the Scrum Leader for outstanding effort during a Sprint.

For example my team recently finished a Sprint 2 days early – this was due to some hard work and innovative solutions to delivering a project. I awarded Blue Sky days to two developers.

From Zero to Hero

What do you do when the business puts you under pressure to start a new project or business process and you don’t have the information you need to get going?

Iteration Zero is a great idea if you have a new team that need to orient to Scrum methodology or you have a large project that needs research or specialist equipment.

The concept is simply that you plan out what will be required to start the project. There may be a situation where an Iteration Zero is required to build the Product Backlog before starting the process of estimating and prioritising.

Peter Schuh has an excellent review of Iteration Zero, which also covers support and refactoring:

http://peterschuh.com/?p=129

If you utilise Iteration Zero, let me know how it goes.

Our dirty little secret

Yes, like all Scrum teams we have a ‘dirty little secret’.

Our secret is we don’t use Story Points.( Queue –  Ken Schwaber running screaming from the building) I’m keen to right this wrong so have been delving in to the world of Story Points;

What are they and why are they important?

I was under the complete misunderstanding that Story Points are a measure of time. I have a industry training in Project Management with Gantt Charts, Network diagrams and Critical Paths.

The abstraction of time to plan capacity for a project seems completely alien to me.  I read, listened and watched videos on the subject and suddenly realised that the concept is quite liberating. Simply put:

“A Story Point is a measure of how difficult a task is”

Many Scrum teams use Small, Medium, Large and Xtra Large to classify the size of projects and Mike Cohn talks about estimating using distance as a concept. A quick job is near, whilst a difficult or complex job is far away.

I will be pursuing Story Points in a simple 1 (Easy task) – 10 (Difficult task) range. There is the added impetus that very shortly we will be using the MS Agile 5.0 templates in TFS and these strongly support the use of User Stories and Points.

I’m looking forward to liberating the team from worries about being locked down to deadlines or having no clue how long a User Story will take. We should rapidly reach a point, after 2 or 3 iterations where we know how many story points we can accept in to a Sprint. I’ll let you know how it goes.

Mike Cohn on Story Points (short video):

Mike Cohn on Story Points (text):
http://blog.mountaingoatsoftware.com/should-companies-measure-productivity-in-story-points-ideal-days

Brief discussion on the use of Story Points :
http://www.infoq.com/news/2010/03/story-points

Long discussion on the Scrum Alliance Group website, on the relative merits of Story Points:
http://groups.google.com/group/scrumalliance/browse_thread/thread/955dc287638e69f5

Ouch!

Ouch!

In our previous Sprint we had a Product Backlog item that we simply did not know enough about to accept in to the Sprint. In response to this challenge we adopted a Spike task. The point (no pun intended) of a Spike is to focus attention on gathering information.

The Spike task was time limited to two days and was in this case completed early. Enough information was gathered to allow the Product Backlog Item to be broken down in to Sprint Backlog Items and added to the next Sprint.

Spikes are handy if there is a requirement to provide answers to a business related or technical question and they also have a cool name.

Discussion on Spikes and Tracer Bullets (used in XP):
http://blog.agilebuddy.com/2009/11/what-is-a-spike-in-scrum.html