Aaron Bjork : Tips

Agile Tip #9 – Motivation 2.0

Aaron Bjork MSFT — Mon, 07 Nov 2011 21:49:50 GMT

In last month’s column of Visual Studio Magazine we talked about Dan Pink’s book DRIVE: The Surprising Truth About What Motivates Us and how it relates to motivating Agile teams.

If you haven’t read Drive, I’d recommend you pick up a copy. For a quick teaser, watch this quick video that animates the main points in the book.

Agile Tip #8 – Planning and Learning

Aaron Bjork MSFT — Thu, 22 Sep 2011 15:00:00 GMT

My column in this month’s issue of Visual Studio Magazine talks about the value gained by Agile teams as they plan and learn.

Agile Tip #7 – Learning From the Past

Aaron Bjork MSFT — Thu, 26 May 2011 14:24:59 GMT

Retrospective meetings have been commonplace in software development teams for many years. Teams hold a meeting at the end of a project or milestone to discuss successes and failures. They use the data from that meeting to look for ways to create more success and less failure in future projects or milestones.

Agile teams in particular have embraced retrospectives as a way to drive continuous improvement into both teams and processes. As stated in one of the twelve principles behind the Agile Manifesto, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." In this month's column, I dissect this principle and examine a few key elements of effective retrospectives. Read the full article at Visual Studio Magazine.

Agile Tip #6 – An Effective Daily Stand-up Meeting

Aaron Bjork MSFT — Fri, 22 Apr 2011 02:45:16 GMT

Yesterday, I published my first installment of a new monthly column I’ll be writing for Visual Studio Magazine. The column will focus on Agile practices and how to use them effectively on your teams. The first installment focuses on holding an effective daily stand-up meeting.

Agile Tip #5 – Learn to Love Acceptance Criteria

Aaron Bjork MSFT — Tue, 04 May 2010 15:07:00 GMT

Tip #5: Start to love and embrace acceptance criteria.

Ask 10 mature agile teams “How do you know when you’re ‘done done’?” and you’ll get the same answer from each one… get serious about writing acceptance criteria.

Acceptance criteria is the handshake between the product owner and the team on what “done done” really means. Until the acceptance criteria is met, the team isn’t done with the story. Period. However, the value of acceptance criteria only starts here. Acceptance criteria provides the stage for some of most meaningful conversations and interactions that can happen on an agile team.

On my own team we routinely have some of our best interactions as we start digging into the acceptance criteria for each story on our backlog. Inevitably we all start with our own ideas about what “done” means for a given story. However, as we begin to discuss the acceptance criteria presented by the product owner what ensues is a series of “ah-ha moments”. A shared understanding of the story begins to emerge. A comment one team member might elicit the following response from someone else… "Ah-ha, great point… I never thought of that.” Regardless of who is being enlightened, the power is in the fact that the product owner and the team are building together a shared understanding of what “done” means for each backlog item. And, this is happening before the team has written a single line of code… before any work has been done… before commitments have been made… and before the sprint has begun. By collaborating on acceptance criteria the team is minimizing risk and greatly increasing the chance of delivering successfully.

I don’t think it’s a coincidence that the first bullet in the Agile Manifesto states “… we have come to value individual and interactions over processes and tools”. Agile teams work together. And by working together, they create better software. Start learning to love acceptance criteria and see if your team isn’t more successful delivering software.

Agile Tip #4 – Plan Using Velocity

Aaron Bjork MSFT — Wed, 28 Apr 2010 16:46:00 GMT

Tip #4: Use velocity when planning iterations.

Before you plan an iteration it’s critical that your team understands its velocity. A team’s velocity is the number of story points that it can complete in a single iteration. Put even more simply, your team’s velocity is how many story points it completed in the last iteration. It’s not how many points the team planned to complete. It’s how many were actually completed based on the acceptance criteria defined by the product owner. This is commonly known as yesterday’s weather. It will take a few iterations before the team will truly understand its velocity, but over time, the team will settle into a common understanding of how many story points it can commit to in a single iteration.

In MSF Agile 5.0 you can use the Product Planning workbook to track your team’s velocity. In the screenshot shown below the team completed 13 story points in iteration 1, 14 story points in iteration 2, and 10 story points in iteration 3. In this example, the team’s velocity is 10 story points… it’s not 12.3 (the average), and it’s not 14 (the max). It’s 10 – the number of story points completed in iteration 3. As the team enters the planning meeting for iteration 4 it should know and understand its velocity so it can have a healthy conversation with the product owner about how many points it can commit to in the next iteration. There are good likely reasons why the team completed fewer points in iteration 3 than iteration 2. Was someone on the team on vacation? Did the team over commit and not complete a story? Those reasons should be known by the team and should have been surfaced during the team’s retrospective.

As the planning meeting begins, the product owner and the team start to discuss and select stories to include in the next iteration. If the top four stories on the product backlog have story points values of 3, the team will know that if they commit to ALL those stories they’ll be committing to more work (12 points) than they completed in the last iteration. If the take only 3 of those stories, they’ll be committing to less work (9 point). In either case, this might okay, but by using the team’s velocity the team and the product owner can have a healthy conversation about what the right stories are for the next iteration.

Using velocity when planning iterations will help your product owner to do better release planning, it will help the team make stronger a commitment, and it will lead to healthier communication with everyone involved. For more on this topic I’d recommend reading Mike Cohn’s book Agile Estimating and Planning.

Agile Tip #3 – Story Point Scales

Aaron Bjork MSFT — Thu, 22 Apr 2010 15:08:00 GMT

Tip #3: Choose a meaningful story points scale for estimating user stories.

The MSF Agile 5.0 template uses story points as the estimation unit for items on the product backlog (User Stories). The field itself is a double and supports different number formats, however teams that use story points successfully agree upfront on a scale that they apply across all stories on their backlog.

Before choosing a scale for your team, it’s important to be comfortable with what story points are. Story points are simply an abstract unit of size (or complexity) assigned to each story on your backlog. They’re not hours, days, weeks, or any other scale that has an absolute measurement. They’re simply “points”. I recommend walking through Mike Cohn’s presentation on Agile Estimating and Planning that goes into specifics on story points and how to use them. They three key advantages he lays out in his presentation are:

Story points force the use of relative estimating
Story points focus on size, not duration
Story points put estimates in units that we can add together

In short, story points provide a relative size for each story on your product backlog that can be used to plan iterations and determine the team’s velocity (amount of work planned or completed in an iteration).

The Fibonacci sequence (1, 2, 3, 5, 8, 13, etc) seems to be the most popular scale being used by Agile teams. It’s well known, non-linear, and provides nicely sized “buckets” that people are comfortable using. Whatever scale your team chooses, be sure that everyone on the team understands it and is committed to using it – you’ll find success with story points easier to come by when your agree on the scale up front.

Agile Tip #2 – Simple User Story Titles

Aaron Bjork MSFT — Mon, 19 Apr 2010 18:43:00 GMT

Tip #2: Write short/simple titles for each user story.

In the MSF Agile 5.0 process, requirements are collected in the form of User Stories. This technique of expressing product requirements has become extremely popular in recent years as the Agile movement has gained momentum. Mike Cohn has a great article on the advantages of writing requirements as User Stories which I’d recommend reading. One of the nice features of the User Story work item in MSF Agile 5.0 is the inclusion of a story template for new stories. The template, “As a <type of user>, I want <some goal> so that <some reason>”, helps express the user involved in the story, the goal the user is trying to achieve, and the value that implementing the story will provide. See Mike Cohn’s guidance on using this template here.

In beta versions of the process template, we included the story template directly in the title of the work item. It worked, and customers loved using the template. But feedback from the community showed that that navigating the product backlog became more difficult when story titles used this template – in short, things became too verbose. We found that most teams preferred to use a simple name for their stories that they could recognize and remember, while still using the story template approach to describe the story in full. To solve this problem we moved the story template into the details tab of the story work item form and left the title blank for users to enter a simple title.

For your stories, write a simple title (just a few words) that your team will recognize and can remember… something the team can refer to in their stand-ups and daily activities. And use the story template on the details tab to to convey the user, goal, and value of the story. Below is an example.

Agile Tips

Aaron Bjork MSFT — Mon, 19 Apr 2010 18:13:00 GMT

With the launch of Visual Studio 2010 last week I thought it would helpful to start a series of blog posts on how you can make the most out of the TFS 2010 process templates.

If you’ve been following any of the beta releases you know that MSF Agile 5.0 is a big release as far as process templates go. I blogged about this late last year after the Beta2 version of the template was released. In short, the template has been completely overhauled to better match the current trends in the Agile software development community. From reports, to work item types, to new dashboards, and even process guidance… MSF Agile 5.0 is brand new!

I’ll update this post regularly with a table of contents tips that you can use to get the most out of your projects using the new template.

If you’ve got questions about the template or would like to suggest a future “tip” I’d love to hear from you.

Agile Tip #1 – Epics and Themes

Aaron Bjork MSFT — Mon, 19 Apr 2010 18:12:00 GMT

Tip #1: Organize your product backlog into epics and themes using parent/child relationships.

It’s common to say that user stories should be small – you want the team to be able to complete the implementation of a user story in a single iteration. However, it’s also common to organize stories into larger buckets called Epics or Themes:

Epics are very large user stories that represent a significant amount of work. Epics are broken down into smaller stories that can be implemented in a single iteration.
Themes are higher level stories that may span the entire project. Themes are used to communicate direction and alignment.

If your team prefers to use epics and themes you’ll want to make some simple changes to the default queries in your team project. The first step is to change your Product Backlog query from a flat list to a tree.

Double-click your Product Backlog query and click the Edit Query button from the query toolbar.
Change the query type to Tree of Work Items
In the linked work items portion of the query change the clause to “Work Item Type = User Story”. This ensures that your Product Backlog will only return user stories, and not other linked work items like tasks, bugs, etc.
Click Save Query.
Make this change to the Product Planning query as well. The Product Planning query is used to drive the Product Planning Excel workbook.

Once this change is made, you can drag and drop stories beneath each other – the parent story then represents the epic or theme. A couple of quick rules to follow to be successful with this approach are as follows:

Don’t add story point values to epics or theme stories after child stories have been created. It’s good to start with a point value for epics that represents how big you think the work is, but once an epic is broken down into smaller stories the child stories get point values assigned and the epic point value is cleared. Themes should never have story point values assigned.
Use decimals to stack rank stories under a theme or epic.
Prefix both epics and themes with their type so that they can be easily distinguished when viewed in a flat list. While a tree is the natural way to view these items, it’s easy to produce queries that return epics and themes in a flat list as well. The prefix makes them easily distinguishable from other stories.

Below is a screenshot of a Product Backlog that has been modified to use Epics.

Tip #1.1: Prioritize epics relative to their child stories.

Martin Rajotte asked a great question related to this topic… “How do we deal with different priorities of stories that are children of Epics? I can’t fit all the stories of an epic into a single iteration.” Because this is quite common, I’ve included a screenshot below of the same backlog, adjusted to accommodate different priorities for child stories that don’t fit in the example above. My recommendation in this scenario is to keep the epic (parent story) prioritized relative to its highest priority child story.

In the screenshot below you’ll notice I added a new epic named “Order Search” with two child stories. The epic is prioritized relative to the highest ranked child story – in this case, “Quick search by title.” When “Quick search by title” is completed, the epic would be reprioritized to to 55 as the highest remaining story (“Advanced search by order details”) is prioritized as 55.1. I still prefer to keep decimal values on the child stories as it’s an easy visual indicator that the story is a child of an epic. This approach allows epics to float up and down the backlog as the relative importance of the stories that make them up are determined.