Agile Dev Stuff

A Day in the Life of a Scrum Master - 9:30 - The Standup

Our standup takes place by the Scrum Wall each day at 9:30am. Every member of our team attends including our Product Owner and every team member talks about what they were working on yesterday, what they’re doing today and any impediments they may have and updates the relevant post-its on the wall. Any new impediments raised are added to our impediment white board for follow-up.

It’s recommended in Scrum that you timebox your standups to 15 minutes, and in our team of 9 standups generally last around 10 minutes. Our team is fairly well established so I rarely have to actually ask “the three questions” (What did you do yesterday? What will you do today? Are there any impediments in your way?). For the most part each team member gives their update in turn without this prompting, although sometimes I do follow up with one of these questions if their update doesn’t address it e.g.

Team Member:I’m finishing off that bug [updates post-it]
Scrum Master:Ok, was that what you were working on yesterday too?

I don’t generally ask each person if they have any impediments even if they don’t specifically say so in their update. A common complaint I’ve heard of “The Three Questions” approach to stand-ups is a general feeling that the questions make the team members feel like they’re being spoken to as if they’re babies or young children. Once a team is the rhythm of answering these questions every day, it seems to me there’s no need to explicitly ask them.

So that’s about it for our morning stand-ups. Team members are able to start the day knowing what everyone else has achieved yesterday and with a plan for what they’ll aim to achieve today. The PO knows exactly how far we are progressing and the Scrum Master has a clear idea of anything that may be impacting on the team’s ability to progress.

A Day in the Life of a Scrum Master - 8:34 - The Burndown

I like to start off the day by updating our burndown chart which yesterday’s changes. At this time in the morning our office is usually very quiet, which means I have nice clear view of our Scrum Wall. Once I’ve updated all the hour estimates on our tasks and added in any new ones, I print off an A4 sized chart of our burndown and put it up next to the Scrum Wall. As I’m currently using Banana Scrum, a typical example looks like this:

The entire process usually only takes a few minutes and ensures the entire team has visibility on the sprint’s progress.

Scrum Tools - A Review - What we use now

You don’t need much in the way of tools and software to do Scrum, but that doesn’t mean there aren’t some great tools out there that can make it a bit easier. Over the next while I’ll be taking a look at some of the different free Scrum software that’s available to see if it can offer any improvements over our current tools.

Managing the Product Backlog

We currently use a custom list on our Sharepoint intranet for our product backlog. It’s highly customisable, so we can add in or remove any fields we want. It’s very easy to create custom views, so we can easily see only items in the current iteration or a prioritised list of uncommitted items or only items still be estimated. We can also email out links to specific items or views so that we can easily share information. Everyone in the company knows how to get to it and how to use it.

The downside to it is that it can be very slow to work with. Each page load can take a while and it can take quite a few clicks to get to the relevant screen for editing and adding items. It means that setting the priorities on 15 items can take about 10 minutes.

Tracking Burndown

We use Excel to keep track of how many hours remain on each task in an iteration. This works fairly well but it would be nice to have all Scrum-related data in the same tool.

What are we looking for?

The first evaluation will be done by me and my Scrum Master colleague. We’ll be looking for tools that allow us to have both product and sprint backlog management in one tool and allows Product Owners to easily update and prioritise the product backlog. It’s also fairly important that you can create custom views or filters of the pbl and that you can send out a link to individual user stories or views in an email.

Next time I’ll be looking at Danube ScrumWorks Basic.

Finding the right iteration (sprint) length

From the blogs and articles I’ve read of different companies have implemented Scrum, it seems that the most popular iteration lengths are either 2 or 4 weeks. When we first adopted Scrum over a year ago we decided to go with a 2 week iteration. I wasn’t Scrum Master at this point so I can’t say for sure why we decided on this length, but there does seem to be a lot of support advocating this as the best choice when beginning with Scrum.

Things to consider

• How quick can we react to change?
  Once an iteration has started, there should be no unforeseen changes to the team’s workload. In theory, if new work comes in then either it will be high enough priority to warrant terminating the current sprint and starting again (NOT something you want to happen on a regular basis, since it means wasted effort on the planning and starting of a sprint) or it waits until the planning meeting for the next sprint. Would the business be happiest having to wait 2 or 3 or 4 weeks for the scrum team to start working on a new piece of work?
• How often should we feed back to the customer?
  At the end of every iteration the customer has the opportunity to review the work that has been completed, allowing them to know if changes are needed early on in the project. The longer the iteration length, the fewer opportunities the customer has review the project.
• How well does the team know Scrum?
  If your team is relatively new to Scrum it may be beneficial to start with a shorter iteration length, since this means the team gets a feel for it quicker and has the opportunity to discuss and improve the Scrum process more often in their retrospectives.
• How big are your user stories?
  A larger iteration length means that a team can tackle larger pieces of work in it.

With our two week iterations, we started to find that some of our user stories got chopped up into “dev stories” to try and make them fit into one iteration. The major issue with this approach is that in a lot of cases, the completed stories could not be properly tested or demonstrated as they consisted of only low-level code changes. It also meant that they could not be properly prioritised by our non-technical product owner.

To solve this problem we are trialling a new three week iteration length. We’ve completed two so far which have gone pretty well. The rest of team like the perceived reduction in overhead, since our planning and review meetings are further apart. We haven’t really had an example of a much larger story yet, so I guess we’ll need to wait and see if we have really solved the “dev story” problem.

Another way to estimate

Recently we’ve been a lot estimating for new features in preparation of our huge quarterly planning sessions. Did I mention it was a lot of estimating? It was a lot of estimating. Some of these estimation sessions ended up lasting a few hours, and after a while the user stories started to blend together. It didn’t help that in some cases this was the first real time the team had seen these stories so they would estimate a story assuming they would have to do certain things in order to complete it and then find out fifteen minutes later that there was another user story specifically covering those things. It seemed relatively clear that we needed a better way to handle these sessions, but it wasn’t immediately obvious what that better way would be.

The answer for us came from Xebia’s blog.

It’s a very simple idea. Write all your user stories out onto strips of paper and then have the team sort them into descending order of size. There’s no talk of story points (or whatever other unit of measurement you normally use for estimation) at this point, just the question “Is this user story bigger or smaller than that user story?” The great thing about this approach is that it really helped generate discussion about the user stories too as the team decided where in list each strip of paper belonged. It was also much easier to keep track of what each user story was compared to viewing them on screen as we normally do.

Once we had our ordered list of user stories it was easy to identify which groups of stories were 8s and which were 5s etc. The team pretty much just drew lines in the list and said “This lot are x, this lot are y”. And that’s it. Done.

Afterwards the team were really positive about this approach. One said he thought it was an improvement over previous meetings and particularly liked the discussions that it generated over the user stories. I think we’ll definitely try this one again when we are faced with a huge list of user stories to try and get through.

Are you really doing Scrum? The Nokia Test

I came across this article recently on a test devised by Nokia to figure out if teams are really doing Scrum or if they just think they are.

There are two parts to the test, the first asks questions based around iterative development and the second focuses on making sure the main aspects of Scrum are present.

From the article:

So the big question then: Are we doing Scrum?

According to the criteria in this test, yes! Of course that’s solely based on my answers to the questions so maybe a poll of my team would yield different results. It would certainly be an interesting insight to see if we had any differences in answers.

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Taken from http://agilemanifesto.org