Canonical Voices

Posts tagged with 'scrum'

Victor Palau

The Ubuntu Certification team is fully distributed and has now been running Scrum for over 9 months. The team has members in Canada&US, Europe and Asia. I have been blogging about several parts of our scrum experience, now is time to piece it all together!

We run in 2 week iteration cycles within a larger 6 month release cadence. Here is what those two weeks look like:

Day1 (Thursday)- Planning session

We run the planning session (30 minutes) just after the previous iteration Demo session – No room to breath! The reason for doing this is just down to timezone and trying to get as many people as possible into this sessions.

We host the planning session in Mumble, and we review the backlog for the next iteration. We found it a bit dull just for the Product Owner to explain what each story was about. Instead, we ensure that everyones participation by agreeing the definition of done for the stories. This eliminates any misunderstandings of what needs to be deliver and ensure that everyone is paying attention.

Just after the planning session, the scrum team gets together to flesh out the task-board for the iteration. At this point the stories are re-size via IRC planning poker: At the count of three by the Scrum Master every one pastes a t-shirt size on the IRC channel.

Following the poker planning, the team discusses possible implementations and they write down tasks in the IRC channel, to be later translated by the Scrum Master into the backlog.

Daily Scrums

We run two scrums (no longer than 15 minutes) a day. A reduced one at 9.30 UK time with Europe and Asia, and a larger one at 15.00 UK time including UK and US. We run both using Mumble but Google+ is also a good option.

Day 5 (Wednesday) – Backlog review with the Scrum Master

On Wendnesday, Ara and I review the progress of the backlog and discuss any stories that might need to be refocused, unblocked or delayed to a later iteration.

Day 6 (Thursday) – Discussing impediments and new ideas

At this point, we have reach the equator of the iteration. We host a 45 minutes meeting following the main scrum to talk about any issues the team wants to raise. This mainly focuses around problems facing our work or new ideas for future iterations or releases.

Also, the Scrum Master send an mid-iteration status email. This ensures that nothing is falling through the cracks and everyone knows the overall iteration progress. We find that scrums tent to focus on what people are working and not what is left in the backlog, this can lead to lower priority user stories being worked on while higher importance ones remain overlooked.

Day 9 (Tuesday) – Backlog review for next iteration

The Scrum Master, Product Owner and I get together to review what stories are likely to not be completed. This is normally 80% accurate and gives us a better idea of how many new stories are to be added for the next iteration. Then, we discuss priority of stories and we create a draft backlog for the next iteration. Although there are always  changes during the planning session, this gives us a solid draft to start from.

Day 11/Next Day 1 (Thursday) – Demo

We completed the full circle and we are back at the demo and planning meeting, where a demo lead shows via Spreed (screen sharing tool) what has been achieved.

Read more
Victor Palau

(this blog has been reproduce from

When working with Agile, make sure to define your long term strategy that gives direction to your product backlog.

The Ubuntu Certification programme follows the beat of the 6 monthly release cadence. In the certification team we run a two week iteration cadence.  It is a continuous delivery machine! The danger is for your ambitions to get stuck in the quick rhythm.

Regardless if I am working with a product or a service team, I found it important to set a clear vision to aim for. The constant cadence of Agile is normally riddle with changes in priorities. While this enables the team to remain flexible, I have found that can be confusing for the individual: “Tell me again why are we doing this?”

Having a clear vision or product road map doesn’t only benefit your team, but also your stakeholders. I often find that a lack of a shared vision creates a mistrust – “This iteration could be the last one. Quick, I better ask for everything I need at once! Everything is high priority!”, sounds familiar?

Sharing a common set of principles and aspiration to deliver great value is sometimes confused with the need to have a committed  two-year plan. To remain competitive, I rather stop second guessing the future and build working practices that allow for change and make people comfortable working with the unknown.

Read more
Victor Palau

The Certification team at Canonical has been Going Agile now for the last 9 months. Oneiric is the first release that we are running full Scrum practices. We are a bit unique as we are spread all over the world. We have 2 people in Montreal (Canada), 1 person in Boston (USA) , 1 person in Raleigh (USA), 3 scatter over the United Kingdom, our Scrum Master is in Germany, and our latest team member is in Taipei (Taiwan). Running Scrum in this type of  environment needs constant innovation. I am keeping track of our progress in my blog at

Roughly every three months, we get together somewhere in the world. We just got back from the Ubuntu Rally in Dublin, where we decided to give our backlog some love!

We largely build our backlog at the Ubuntu Developer Summits and then we continue to add and remove items as we go.

Halfway through the project and with over 100 items to complete before the end of October, we needed to step back and make sure that we were working on the right priorities and that nothing had fallen trough the cracks. What better way to do this than a full poker planning session. Here is how it worked:

  • We use real cards that I brought over from home
  • We clear up a round table big enough to fit the whole team and we booked an hour and a half for the session.
  • We had a house dealer: I chair the session, I did not participate on the poker, my computer was the only one allowed at the table.
  • Using the list view in our google docs backlog, we reviewed a blueprint at the time
  • We spent less than 90 seconds per use case.
  • We use the following t-shirt sizes as measure of effort required to complete a use case: S,M,L & XL
  • Where there was substantial disagreement on size, we asked the highest and lowest  bid to briefly reason their decision. If needed, we did another sizing round after that.
We did came out of the session with a better sized backlog. The biggest benefit for me was that we merged, deleted and added new stories based on what we had learned over the last few months of implementation.
I also had to make some tough choices based on the new information and I decided to removes some blueprints from our Oneiric backlog scope.

Poker by Jonathan Rubio

Read more
Victor Palau

After the Ubuntu Summit in Budapest, We were faced with a lengthy backlog for the next 6 months. We made sure that we wouldn’t waste too much time on defining in great detail stories that would not be executed until 3 or 4 months from now. The result is that the next month worth of stories are smaller and more granular and large stories are found towards the bottom of the backlog. So far so good.

Like any successful team ;) we have more work that we wish we could do than we can actually fit over the next 6 months. To reduce scope, I needed to at least defined what is our estimated capacity for the 6 months and compare it with the current backlog.

To be accurate, we would need to estimate the size of every story in the backlog, in a more consistent manner than asking a team member for their gut-feeling (current process). We discussed having a Late Night Poker session at Budapest where we would size every single story, however this strike me as not agile at all.

Having discarded the massive Poker Planning session, I started looking with the Scrum Master at other options: Monthly Poker, Next Iteration Poker…and so on.

Eventually, I decided that I was looking in the wrong direction. We are going to continue doing planning poker for the Iteration that we are about to start and we will need to leave with the uncertainty of our backlog.

One thing was certain, that our backlog was too large and needed trimming down. Looking at our team’s velocity, I noticed that it was not only consistent on the story points but also fairly consistent on the number of stories completed per iteration. Saying this, I set out to cut down the backlog assuming that we completed 7 stories per iteration and that the last iteration should be empty. Clearly, this is not 100% accurate, maybe not even 80%, but it is a good starting point.

Agile is about managing change and living with uncertainty, and I’ve realised that I was trying to bend that in to good-old false security feeling of predictability.

Read more
Victor Palau

I have commented several times on the 2-weekly cadence that we follow at the certification team, but I haven’t gone into much detail on our 6 monthly cycle. We have just completed the Natty cycle (normally release date + 2/3 weeks) and we are about to start our Oneiric one.

6 monthly cycles help to plan achieving longer goals that drive the user stories implemented by the team in each iteration/sprint. During Natty, we had a loose coupling between these two.  I regularly (once a month) reviewed the progress of the Natty backlog and made sure that nothing was falling through the cracks. Despite the good completion rate in Natty, it was more of a case of the user stories forming the Blueprints (6 monthly requirements) than the other way around.

For Oneiric, the certification team went into UDS-O with much better defined blueprints. This has not only resulted in better sessions, but also on well defined backlog. Clearly, there is no much point trying to tight down what we will be doing in 4/5 months, so user stories towards the end of the cycle are vague and fairly large.  User stories for the next 2 months are better understood and described.

We have been collecting velocity data for the last few months, so by asking the team to roughly size new stories and review the sizes for the “next_iteration+1″, I hope to be able to build a burn up/down chart over the next few weeks! I will keep you posted.

Read more
Victor Palau

While trying to work out the best way to adopt Scrum in the Ubuntu Certification team, I didn’t want to commit to an expensive process tool. So we have end up developing overtime the ultimate Google Document SCRUM tool.

I didn’t want to spent too much time reviewing tools and shopping for better prices rather than working on embedding the process correctly in the team. We might eventually move to a hosted “funky” web 2.0 solution, but in the meantime, Google Docs is doing the job just fine.

I thought that it will be great to share our backlog template with everyone, so I have created a public template with some fake stories. Here is the breakdown on how it works:

Iteration Backlog Tab

I like the idea of using a spreadsheet for the backlog because it is very easy to re-arrange based on priorities.

  • Each row is a new story.
  • The main body of the story is split between 3 columns: As.., I want to.., So I can..
  • We list the priority in row E. Anything with 1.x priority is for this iteration. The next iteration has priorities are 2.x, anything else has priorities 30,40,50 or 100.
  • We have created dividers that have the number 2 and 3 as a priority. Using the Sort function will automatically arrange the backlog correctly.
  • The definition of done is also there ready to go. You will notice that the row/column freeze panels focus either on planning or demoing.
  • In a remote team, it makes sense getting a bit more organised. Column H – Demo lead designates the person that the team has agreed will demo the story at the review meeting. This person is in charge of preparing in advance the demo and adding the links and notes to the backlog.
  • We link back to our 6 months epics (or blueprints) per each story in the backlog
  • Once the stories are agreed as Done at the review, they get moved to the Done tab.

Task board Tab

This tab is used on daily basis by the team and reviewed during the Scrum.

  • Each story is broken down into tasks
  • A task only gets names against it once someone has started it
  • Task status cells (in aubergine) can have white text and links pointing to progress or problems
  • To move the status of a task just cut (CTRL+X) the aubergine cell into the new location (CRTL+V)

Velocity Tab

We have just started to use this tab, so we will see how it goes.

  • We use T-shirt sizes that then are translated to story points using part of the Fibonacci series.
  • The backlog size for the iteration is calculated in cell $I$1.  As the backlog size changes from iteration to iteration (not only due to completed stories but also new ones added) , you will need to manually record the backlog size in column G. This will give you enough information (together with the velocity in column F) to forecast when the backlog will reach 0.


If you want to make your own copy to play with,  just download it as an xls and imported back within your Google account. As usual, I would like to hear from you suggestions to improve the process, happy scrum!

Once more the link to the template –

Read more
Victor Palau

I wrote recently about the Ubuntu Hardware Certification team transition to Scrum.  We have since completed a few iterations, which means that the Planning and Demo sessions are in full swing. I am also happy to say that we now have a full-time Scrum Master in the team. One of the key advantages of this is that I get to sit in the demos and ask questions “from the outside” :)

Because of the global distribution of my team, we have end up with back-to-back Demo/Review and Planning meetings. This is how it goes:

3pm UTC – Demo meeting (30 minutes)

The Scrum Master runs (using Mumble) through all the user stories in the backlog.  Previous to the meeting, team members have posted links to their demos. We share the demos using a “virtual meeting” tool.  We end up settling for Spreed, as we already had some company accounts ( but I still secretly love yuuguu!).

At the end of each demo we [product owner, scrum master and me] give our opinion on whether the user story is completed or should be carried over to the next iteration (or later).

3.30pm UTC – Planning meeting (30 minutes)

The product owner runs over the next set of user stories for the upcoming iteration and explains why they have been chosen and what is required to complete them. The team is encourage to ask clarification questions.

This meeting is run using mumble and the iteration backlog (stored in a google doc).

4pm UTC – Taskboard (1 hour)

After the call concludes (and following a 5 minutes break) the team gathers back at the IRC channel to start breaking down the stories into tasks. The whole backlog is fleshed out and added to the taskboard. After that, team members are asked to start assigning tasks to themselves .


So what do we still need to work on? Here is a shortlist:

  • Sizing User Stories – did you say IRC Poker Planning?
  • Working out a velocity for the team
  • Iteration and Release Burn-down charts
  • Definition of Done

Read more
Victor Palau

The Sprint Taks Board

Last week I had the chance to run Rick Spencer’s Test Sprint. In Canonical-jargon a sprint is normally a 1-week workshop around a specific topic. In this case the topic was Automated Testing, hence my team was participating in the sprint.

As this was my first sprint at Canonical, I got thinking: what would be the best way to ensure a tangible outcome after a week of locking up 10 engineers in the same room? It seemed a good idea to borrow some SCRUM practices to organise the sprint. Here is a summary of what we did:

A backlog

Rick had provided 3 main goals for the sprint. Creating a backlog around these seemed overkill so I decided against it.

This is probably the case from most workshops – if you have so many goals that you need to prioritise them into a backlog, then the workshop is probably lacking focus.

#1 Ceremony: Planning

My approach was to split this into pre-sprint homework and a 2 hour session on the morning of the first day. The pre-sprint homework consisted on people getting together online to break down the 3 top goals into tasks and deciding what could be done. This helped focusing people’s mind in the problem, but at the end of the week most of the task created during the sprint were replaced or chucked away.

The planning session at the actual sprint was really good. It made sure people had the same expectations of what needed to be achieved on during the week, and it help building up a very useful set of tasks to get there.

#2 Ceremony:Demo/Review

From the start, this was a definitive yes from me! Having a demo at the end of the week meant that we all walked away understanding the accomplishments and short comings of the work achieved during the week. It also helped us decide on the next steps to follow after the sprint.

#3 Ceremony: Stand-ups

Having only a week to work, it was very important to me that communication was not an impediment. Also, that I was not interrupting engineers with status reports: “So, what are you up to?”.  I scheduled two stand-ups per day: First thing in the morning and first thing after lunch.

While having stand-ups (IMHO) worked great, I am still unsure if 2-a-day was really needed. It felt that some days it really made a difference (specially at the start of the week) while others there wasn’t that much to talk about at the second meeting.

#4 Ceremony: Retrospective

As this workshops tent to be a one-off, I decided not to this. We do run sprints regularly, so it might be worth it to do a retrospective on ” how to organise a sprint”. But definitely do this offline, no need to spent valuable face to face time.

Task Board

My experience of physical Task Boards is that they are great at focusing the team on making progress and tackling blocking issues. Having everyone in the same room, it seemed that a Task Board was ideal. And it worked great!

My tips about physical Task Boards are:

  • Use index cards and not post-it notes – trust me on this one.
  • Use Sharpies. Normal pens are too small so people end up writing too much in the cards, while whiteboard markers have the opposite effect.
  • Use coloured cards. Choose one colour per Goal/User Story. Easy to spot from the distance :)
  • Keep it simple. I would recommend to have only 4 columns: Not Started, In Progress, Blocked, Done.

..and Self-organisation

This for me was a must, specially as we had volunteers from other team attending. The last thing I wanted was to push people into tasks they did not want to do.


Thanks a lot to everyone that participated on the Test Sprint! We worked hard and had lots of fun

Read more
Victor Palau

Now that we are scrumming daily and we have agreed a 2 weeks cadence, it is time to start planning for the next set of meetings: Planning, Demos (Reviews) and Retrospectives.

Scrum has four meetings or ceremonies that you must do within a iteration. Here is how they are described by the Scrum Alliance

  • Planning: the team meets with the product owner to choose a set of work to deliver during a sprint
  • Daily scrum: the team meets each day to share struggles and progress
  • Demo/Reviews: the team demonstrates to the product owner what it has completed during the sprint
  • Retrospectives: the team looks for ways to improve the product and the process.

Show me the money!

The value in Demo meetings is that you get to see what the team has done and how it brings value to your customers. However, it is not as simple as it sounds… there are two things that can make a Demo inefficient:

  • Lack of preparation – people scrambling for demos, you hear things such as “it used to work 2 hours ago, but it is broken now due to work for the next iteration”
  • Old habits (die hard) – the tendency is still to ask people “did you finish?”, and  then tick the box, rather than “show me what you did?”

This is pretty challenging to do remotely, hence I have enlisted the help of technology. After researching what screen-sharing tools work well within Ubuntu and which ones did not require any software to be installed by the viewers, I selected Yuuguu.  It seems very easy to use, simple and the license cost is cheaper than other alternatives. We will try it this Thursday and see how it goes.

Demo meetings are also a good opportunity to discuss if something is really really done (or not)

Planning for the next iteration

The Planning meeting aim is to agree:

  • What is the priority order for User Stories to be delivered in the next iteration (Product Owner)
  • How much work can be delivered in the next iteration (Team)

Then the team needs to start breaking down into tasks the User Stories, and start forming the task board for the next 2 weeks.

Scheduling the Meetings

As Planning meetings happen at the start of the iteration and Demos at the end, this means that Demo.n and Planning.n+1 need to happen pretty close.  I have participated on same-day Morning Demos and Afternoon Planning sessions. However, this is not an option for us due to the timezones that the Ubuntu Certification team is spread over. To minimise the number of meetings we have, we are going to re-use our weekly meetings for the Scum ceremonies.

Every other week, the team 1-hour-call will be a 30 minutes Demo, followed by 30 minutes Planning, followed by 30 mins in IRC to elavorate the task board for the iteration. This is a pretty packed schedule! In my last team, Demo sessions lasted 1 hour, but that was for 3 scrum teams. However, I am uneasy at running Demo and Planning sessions back to back. This doesn’t allow enough time for the Demo outcome to feed into the Planning. We will have to see how it goes.

The weeks in between, we will hold a “open topic” meeting that I hope covers the value of the retrospective.  The team has already a good culture of self-review and raising areas for improvements, so a regular forum to discuss them will be great!

Read more
Victor Palau

Working with a fully distributed team has made me appreciate the beauty of having face time with your team!  Hence, I took the opportunity at UDS to get more acquainted with my colleagues.

Scrum by DarkMatter

As a first part to introducing Scrum to the team, we defined the high level goals (or Epics) for the 6 month release cycle. Part of what I have been trying to figure out is how to use the tools we have at-hand to get started. For the 6 months sprint backlog, we finally settle on launchpad blueprints. We are basically using a planning project within Launchpad, that will have a milestone per sprint/release. By prioritizing and assigning blueprints against the milestone, we get the backlog view.

Back at Symbian, we started by setting up daily scrums and weekly iteration backlogs. However, once the machine had started we struggled to define long term goals. It is hard to get out from the 2 week mindset.

Hence, with HW certification team at Canonical, I decided to prioritise the longer term goals. This was made very easy by the regular cadence of Ubuntu releases. The next step was introducing daily scrums and a 2 week iteration cadence within the 6 months sprints.

Are you standing up at the other end of the line?

With a fully distributed team, introducing regular formalised communication seems on paper an easy win. However, the trick is in the implementation. How do you do it? We decided not to have IRC meetings, based on previous experience. Eventually,  people did not read the comments from others and waited until their name pinged in the IRC channel to post a pre-baked update.  Another option was to Mumble our way through it!

Mumble is widely use in Canonical, so I thought – why not! The first day was short of a disaster. At least 2 people from the team never made it. We had so many issues with headphones not working, that we finally started 10 minutes late – quite bad for a 15 minutes meeting.  I think Mumble is one of those systems that gets better the more you use it. So we will keep our weekly meetings in Mumble, but it didn’t cut the mustard for daily scrums.

Another point against Mumble is the global time zones.  It is great to use computer based systems, if your computer is already on, you are ready for your day and so on… However with people in Asia, US and Europe, the daily scrum is always going to be outside someone’s core-hours.  We settled on a phone conference bridge. So far is going great! We did fail victim to the different daylight savings switch-days between the US and Europe. Can someone explain me why, oh why!?

Iteration Backlog and Task Board

Having proven at Symbian that the all mighty Google-excel was able to deliver a usable Iteration Backlog, I proceeded to extended to host a Task Board.

The important thing is to remember what task board are about – visual aids! Ours is colourful and simple. It has a columns for  ID, Title,  Assignee, Not Started, In Progress, Blocked and Done. The last four are brightly coloured cells that can be easily copy&pasted. What can I say, it doesn’t beat the real deal but this will do for the moment.

Next episode – The Demo and Planning sessions!

Read more