Agileista

In a development environment it can be tricky to know what to measure. There are plenty of potential performance metrics to choose from, everything is done on a computer so naturally you can track and measure it. The problem is one of choice. Whatever metrics you define as your criteria for success will become the focus for improvement. Hence the power of both measuring and rewarding salespeople on pure sales numbers.

For developers, measure lines of code (LOC) committed and they will duly write more LOC. LOC alone means nothing; it could be crappy code right? It's better to measure for the outcome you want. Find some way of measuring quality and that becomes the incentive. Measure it and the team will naturally seek to improve it.

In Scrum there is the team's sprint burndown, which shows how quickly they get through their story points and how likely they are to finish the sprint tasks. A longer trend you could measure is release planning, where you do a similar thing to a burndown but for the whole project/release.

This is all fine for estimating and project planning but in measuring quality it's not much help. Again, what you measure as 'quality' will depend on your situation but some possibilities include: unit test coverage, defect count, uptime, customer feedback, use statistics. Whatever it is you measure, make sure you can get the data reliably and at the right level of detail.

Like it or not, visibility is one of the traits that Agile brings to the party. This visibility is a natural output of Agile process and forms an important part of the inspect and adapt feedback loop. You must be able to see what's going on so you can diagnose problems and make appropriate changes.

What you see of your project depends on what you measure; what you measure will be affected by the measuring. This is an important and related feedback cycle - setting metrics will shape project outcomes (I'll cover this in detail in my next post)

One of the metrics collected in Scrum is the estimated number of task hours remaining in the Sprint. We can use this information to create what is called a Burndown chart. A burndown chart is basically the team's remaining estimated time plotted against remaining time. The shape of this chart can help the Scrum master to see how well an iteration is going and to plan ahead for the coming iteration. To keep track of the software build as a whole a Release and Product Burndown can be used. This will track team output vs. time to release

The first step is in estimating tasks for users stories. User stories that have been chosen for a Sprint need to be unbundled into smaller actionable tasks. By doing this the team get a much clearer picture of the user story and tasks can then be estimated in 'man hours to complete'.

Estimates for each active task are updated by team members as they work their way through a Sprint. When a task is complete it is updated to show zero hours remaining. If a task is not completed by the end of that day it is re-estimated to reflect time remaining to complete it. This information is used to track the amount of work hours remaining in a given iteration; the Burndown chart.

This detailed level of time tracking can make some developers feel uncomfortable; they can feel that they are being monitored for efficiency like workers on a widget production line. When this happens team members may not update their hours on tasks and may slip into simply reporting a task is finished - some may not even do that!

Sprint Burndown charts become inaccurate and difficult to create when this happens. The teams ability to work together can be inhibited by this kind of scenario too. No one knows what's being worked on and the inevitable clashes begin. Luckily for us Boris Gloger and Tobias Mayer have come up with a simple and elegant solution.

During Sprint planning the team should not estimate the amount of time to complete a task, but simply ensure that each task is sufficiently small enough to be completed in a work day. By doing this a Burndown chart can still be produced and the team don't feel like they are being production line managed.

A by-product of this approach is that the team task board becomes much simpler and more effective. Every day during the 15 min Scrum meeting team members move their chosen tasks for the day into the In Progress column of the board and throughout the day those tasks are completed and moved to the appropriate column. This provides the transparency and team visibility that Agile promises and management demands.

The first thing you need to begin Scrum is a Product Backlog. This is essentially a list of features or in my case user stories. This initial list - just enough to get you started - should be prioritised by the Product Owner according to business priorities. Next you'll need to decide on your iteration lengths. Typically a team starts with iteration lengths of 30 days but some teams prefer 2 week iterations.

Now you're ready to begin Sprint planning. Sprint planning is usually split into 2 four hour section - during the initial phase of planning the Development Team sit with the Product Owner and the Scrum Master to estimate items on the Product Backlog. These should be sized according to their relative complexity - that is 'how big is this feature?' not 'how long will it take?' Points are awarded to each User Story. This meeting is usually time-boxed to around 4 hours with as many features as possible estimated in that time. Times for daily scrums and the end of Sprint Review and Sprint Retrospective are also agreed.

With the backlog estimated and prioritised the team work out how many of the most important items on the Product Backlog they think they can do in the allotted Iteration or Sprint period. This can be based on the teams current Velocity if the team have been sprinting together for a while or it can be based on the expert opinion of the team. Based on the items chosen from the Product Backlog a Sprint Goal is agreed with the Product Owner.

For the second half of Sprint Planning the team take the list of items to be worked on during the Sprint - the Sprint Backlog - and break down each item into more granular tasks covering everything from coding to meetings. These tasks are estimated in hours to complete. The team then commits to deliver the functionality in the Sprint Backlog along with the overall Sprint Goal.

Once the Sprint begins there are daily meetings of around 15 min where the team gets a chance to inspect and adapt again. Three key questions are asked: What have you done, what are you going to do and what has been an impediment to your work? It is then the Scrum Masters role to work with the business to remove those impediments to progress for the team.

Once the iteration comes to a close the larger inspect and adapt cycle kicks in. There is a Sprint Review with the product owner to go over all the code completed in that iteration. The Product Owner runs through the software to be sure it meets the original requirements and if it does the team are awarded the points for each user story deemed complete. These team points are their Velocity - a measure of the amount of functionality/complexity that they can deliver per iteration. This review period is also a chance for the team to share their work and get feedback from the rest of the company.

The best time for a Sprint Retrospective is right at the end of the iteration. During the retrospective the team looks at what went well and what didn't and looks to adapt accordingly. Once the retrospective has been held its back to Sprint Planning and the iteration cycle kicks in again.

Some further reading.

Books:

Agile Project Management with Scrum

Agile software Developement with Scrum

Websites:

Control Chaos

Agile Alliance

Scrum Alliance

C2 Wiki

Scrums Wiki

Ron Jeffries

Mike Cohen

Jeff Sutherland