Day 1 is FEW Bourbon, a “spirit drink” that’s 46.5% alcohol. Made in USA.
Initially, I thought it had a light nose, but that turned out to be an illusion – I’m keeping the calendar in the music room, near a bay window, and it’s a mite chilly, so the bourbon was cold. Once it warmed up, it had a definite boozy quality to it, with light corn notes. Not raw corn, but definitely some corn in there. And maybe a bit of honey.
Flavor was decent, with definite corn (hard to avoid with that being part of the aroma, after all) and a burn like fire going down. Fairly smooth. It got boozier as it warmed, not just in the nose but on the palate.
Christina liked it and said she’d drink it straight. She then went and looked it up, and found that the distillery is named for Frances Elizabeth Willard, president of the Women’s Christian Temperance Union from 1879-1898. Which is kind of cool, since Ms. Willard was active in a variety of causes including women’s suffrage.
I rate this one two stars. I don’t know what the scale is yet, but two stars is decent.
This year, my awesome and thoughtful wife Christina got me an Advent Calendar for my birthday. It’s filled with bourbon.
So here goes, the Tour de Bourbon 2015.
An agile board (also known as a Task Board) gives a team an easy way to understand at a glance what they’ve committed to in a sprint and what progress they’re making. The simplest version of this is a set of index cards and a whiteboard.
Create one index card for each of the Stories in your Sprint. The front (unlined) side of the card has the name of the story, along with the estimate (in points).
The back of the card holds other information, such as acceptance criteria.
Make three columns on the whiteboard, from left to right. Label them:
- To Do
Put all of your cards in the first column, with the most important at the top.
People markers (optional but highly recommended)
Create a marker for each of the people on the team. Each person only gets one – after all, you can only work on one thing at a time, right? You can use sticky notes, or magnetic markers on a metal-backed whiteboard.
Put these in the “To Do” column to start.
Putting it to work
Starting at the top of the “To Do”‘ column, determine who’s going to work on the first story card. That person moves the card into the “Doing” column and puts their marker on it. Repeat this until everyone has a task in the “Doing” column.
|Don’t move things until you start working on them! That way lies madness.|
Important Safety Tips
Don’t skip items
If you find yourself skipping items in the “To Do” column, ask why. They’re supposed to be in priority order, so why isn’t the team working on them in that order? If it’s a priority problem, have the Product Owner re-sequence them.
Only work on one thing at a time
You only have one marker for a reason: task-switching is inefficient. Unless you’re actually blocked, you almost always have things to do that will move the story forward. Do those and focus on getting the story to “Done.”
Stay on target
Once you pick up a story, stick with it until it’s “Done.” If you become blocked, indicate this by:
- Turning the card sideways
- Bringing it up in the next Standup
Respect the Sprint Plan
Make sure that:
- There is a card for the work you are doing
- That card is in the sprint
When is a story done?
When the developer is finished? When it passes QA? When the business signs off? When it’s scheduled for a release? When it’s checked in to a release build?
Or is it when the feature is actually in production delivering value?
It’s likely that it’s some combination of the above, and that the answer will vary from team to team, and possibly from story to story. Having a general consensus on the team about what “done” means is important, because without it, we’re going to have confusion.
Accordingly, during the formation process, teams should spend time discussing what their shared understanding of “done” is and recording that in a wiki (or on a poster, or something – just make sure it’s recorded and available to refer back to).
I suggest timeboxing this discussion to 30 minutes. That should be enough to get to at least a high-level understanding. If you’re not close after 30 minutes, get help from a coach to create a compromise position and discuss it in your next Retrospective.
A feature is Done when:
- It passes all Acceptance Criteria
- It passes regression testing
- The requester has seen and approved it in non-Prod environments
- All unit and functional tests associated with it are passing
- It’s checked in to Main (if it’s a code change)
- It’s scheduled for release to production (if it’s a 3rd party change)
- Monitoring is in place (if applicable)
- Support documentation is in the wiki (if applicable)
The Agile Manifesto starts off with:
We are uncovering better ways of developing software by doing it and helping others do it.
And the 12 Principles behind it end with:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile at its core is fundamentally about adapting to changing circumstances. There is no single “right way” to do things that is always correct in all circumstances. Accordingly, agile teams need to spend some of their time getting better at the process of delivery, in whatever ways work for that team in that circumstance.
The Retrospective session is the key to this.
In addition to the very good advice found here, my keys to Retrospective success are:
- Make sure that all dedicated team members attend
- Only allow the dedicated team (and a facilitator) to attend (no visitors or observers)
- Provide a private space so people can speak freely
- Emphasize that this is a safe space so people can speak freely
- Remind the team to assume positive intent
Agile teams are defined in part by their rhythms – the set of meetings and events that the team holds. This is a starter set of rhythms to adopt; once you get up and running, adjust as needed to fit the needs of your team.
Keeping the team engaged and aware of one another is important. In addition to working in the same location to enable opportunistic sharing of information, holding a Standup every day is a critical part of thinking and acting like a team.
Standup is held daily at the start of the work day. It should be quick – 60-90 seconds per team member – and focused on sharing information. Attendees should be limited to people who are directly engaged with the team on a daily or near-daily basis (all of the “dedicated” team members, in Etsy terms, and “designated” team members as needed). Generally speaking, Stakeholders do not attend the daily standup.
In the standup, you’re going to spend more time listening than you do talking. This is a good thing; sharing is a two-way street.
When it’s your turn to talk, there are three key pieces of information to share in your 60-90 seconds:
- What you worked on yesterday
- What you’re going to work on today
- Anything that’s keeping you from getting things done right now (or that will soon)
If you have other things to share, or to ask about, consider implementing a Parking Lot for post-Standup discussion.
Backlog Grooming (weekly or biweekly)
Keeping the Backlog healthy requires ongoing work. The Product Owner should have a regularly scheduled meeting to provide time for this. For more, see Backlog Grooming.
Demo Prep (biweekly)
The day prior to the end of the Sprint, the team should hold a brief Demo Planning session; this can often be handled at the end of the Standup for that day. The intent is to determine
- Which stories will be included in the Demo
- Who will be doing the Demo for each story
Remember that you should only Demo things which are actually Done. Do not include work-in-progress in a Demo!
Sprint Changeover (biweekly)
The end of the Sprint is a set of activities that take several hours. Beginning teams will find that they spend up to a full day on this, while experienced teams will often be able to get through these meetings in a few hours. Resist the urge to speed things up – speed will come naturally as the team builds expertise with the process and comfort with one another. There are three key activities
The first part of the Sprint Changeover is the Demo. This is a meeting where the Stakeholders and any other interested parties are invited. The purpose is to show off the team’s completed work and get feedback (and credit) for it.
|The person who requested a story should never be surprised in the Demo. Always review stories with the requester before the Demo – if you don’t, how do you know they’re Done?|
This meeting should take about an hour, and each team member should be able to show off work at some point. Not all team members enjoying being in the spotlight of the Demo, so be sensitive to that, but make sure that you’re giving everyone a chance to receive credit and praise for their work.
After the Demo, the team needs to have time together in a private, safe space to talk about how things went in the Sprint and what parts of the process the team wants to – and is able to – improve. See Retrospective for more. Allow at least 2 hours for this activity.
The last part of the Sprint Changeover is Sprint Planning.
Sprint Planning is a regular meeting where the team comes together to select and commit to a set of work for the next Sprint. It should occur at the transition point between Sprints, so we have the most information possible about the previous Sprint.
Before the team can plan a Sprint, they need a healthy Backlog. Making sure that the backlog is ready is the responsibility of the Product Owner, who coordinates the Backlog Grooming meeting to make this happen.
The full Squad – Engineers, BA, QA, Product Owner, Delivery Manager. This is the full team making a commitment to get work done as a team, so everyone should be present. Team members on vacation get a pass, but everyone should clear calendars to make this meeting a priority.
The team reviews its Velocity – the amount of work it’s completed, on average, in recent Sprints – and uses that to determine how much work it can comfortably commit to take on.
Working from the top of the Backlog, the team moves stories into the Sprint until it reaches the Velocity limit.
The team discusses the Sprint and makes sure they’re all comfortable that this Sprint delivers value and is definitely going to get done.
The Product Owner confirms that the stories selected for inclusion are the right ones, and potentially moves some stories out to bring others in – staying within the Velocity limit.
Resist the temptation to overcommit. If something really needs to get done in this Sprint, put it in there but take something else out to make room.
Acceptance Criteria are a key part of stories – they provide the guidance to let the team know when a given feature is complete according to the needs of the customer. Often, teams will use Acceptance Criteria to guide the creation of test cases, including both automated and manual tests.
Acceptance Criteria are clear statements that encompass both functional (“when a user clicks the BUY button the item should be added to the user’s cart”) and non-functional (“the BUY button should be green”) requirements.
Examples of good acceptance criteria:
- A user with the Administrator role can create a new user account
- A user who does not have the Administrator role cannot create a new user account
- Creating a new user account requires username and employee ID
- Passwords must be 8 to 20 characters long
Acceptance Criteria can also be defined as scenarios in given/when/then format:
- Given I am a registered user who has selected “remember me” when logging in
- When I return to the site
- Then I should be logged in automatically without requiring a password
The purpose of estimating stories is to allow teams to understand their relative size and use that in Sprint Planning. Often, teams will use “points” rather than hours to emphasize that they’re not estimating the exact work effort.
I really, really prefer using a simple scale* for estimating to start with: 0, 1, 2, 4, 8
0 – such a trivial amount of effort that it doesn’t count. This is rare, but it happens.
1 – “easy” – a small amount of work.
2 – “hard” – a significant amount of work.
4 – “really hard” – a very significant amount of work.
8 – “really, really hard” – a huge amount of work. This is often an indication that we need to do Story Breakdown on this story.
- Review the story as a team, reading the title, description and any acceptance criteria aloud.
- Ask if the team is ready to estimate
- If no, determine what’s needed to get to ready
- Discuss the story as needed to ensure that the team has a shared understanding of who is asking, what they’re asking for and the value they expect to get out of it.
- This may result in the creation of Acceptance Criteria or other additional information – if so, capture those on the story card.
- This may also result in Story Breakdown – if so, capture that information and come back to Estimation as soon as practicable.
- Ask for an estimate
- Each team member decides on a number and then all show at the same time
- If there is more than one estimate
- If there is a minority with another number, ask them to explain why, then re-estimate
- If the team is split, go with the higher number
*Why not Fibonacci? Because I really, really don’t like it. It was clearly chosen by a math-head who doesn’t get human psychology. What’s the difference between a 2 and a 3? A 5 and an 8? Why do we have so many choices? It gives a false sense of precision that does a disservice to the process.
Good user stories follow the INVEST model created by Bill Wake (http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/).
- Independent – can be done on its own
- Negotiable – describes the outcome rather than the specific implementation (leaving us room to negotiate)
- Valuable – delivers value (either business value or knowledge valuable – there must be an outcome!)
- Estimable – we have some idea of how much work it is (other than “a whole lot”)
- Small – a few person-days of work, so we can get it done in one Sprint
- Testable – there are concrete ways of knowing whether or not this is done and works as required
Often, we’ll find that our stories don’t meet these criteria. One particular challenge is making stories Small, because user requests are often for fully realized functionality. The challenge is to find a way to break up a large story into smaller, more easily deliverable units of work.
Note that this isn’t the same thing as Minimum Viable Product – that’s about figuring out the minimum set of functionality that is required for a request to be worthwhile. An MVP is still likely to include a number of stories.
There are a number of techniques for breaking down stories – a good summary is here: http://www.agileforall.com/2009/10/patterns-for-splitting-user-stories/
And an excellent flowchart is here: http://www.agileforall.com/2012/01/new-story-splitting-resource/