Agile Techniques

There are a variety of agile techniques that may have originated with one methodology, and have been adapted perhaps with a different name or different suggested process and used in another agile methodology.

Many agile techniques that originated with XP such as test-driven development, pair programming and continuous integration, for example, are being used in Scrum environments -- not because they are mandated by Scrum, but because teams have tried them and found the techniques useful.

The daily standup meeting, for example, is a short meeting each day with all team members, and is an opportunity to reflect, tune and adjust. The daily standup originated in XP, but has been adapted to use in Scrum and is often called “the daily scrum" or “Scrum meeting."

Many teams, even if they are not using all the recommendations of a certain methodology, such as Scrum or XP, may decide to have standup meetings and retrospectives. Even teams using a phased methodology such as waterfall may have “lessons learned" meetings in which the team reflects on past effectiveness with the intention of improving.

So, let's look closer at some of the agile techniques used today, and where they came from ...

User Stories

User stories are brief descriptions of requirements that get refined over time as it gets closer to the time they will be implemented. The concept of user stories originated in XP as an alternative to use cases, a more comprehensive approach to requirement documentation used in rational unified process (RUP).

User stories typically start with a short statement that describes the role (who), goal (what) and benefit (why) of the requirement. These short statements are purposely kept brief enough to fit on an index card or sticky note and prioritized in a product backlog.

In the Scrum Guide, items on a product backlog are referred to as product backlog items (PBIs), and user stories, as well as maintenance work, would be considered PBIs.

As the user stories reach the top of the prioritized product backlog, the cross-functional team has a “conversation" to discuss the details. Note that rather than a traditional lengthy requirements document in which there might be misunderstandings, this approach is meant to be one in which the team asks a lot of questions of the business representative to ensure there is a clear and common understanding of the requirements.

The team agrees upon the “definition of done" to make sure everyone is in agreement of the expectations and acceptance criteria for the story. The Three C's, a phrase coined by Ron Jeffries to describe the components of a user story, are: Card, Conversation and Confirmation.

Story Points

Story points are an agile technique that is used as a type of metric for estimating the complexity or level of difficulty of a user story. The idea of using story points is that it removes the need for time accuracy when there are still a lot of unknowns.

The more unknowns there are, the less precise estimates are going to be; however, story points use the notion of relative sizing. In other words, stories that are about the same size would have the same number of points. Those that are more complex would have more points and less complex would have less points.

By using a story-pointing system, the team is able to more quickly give a story point estimate that can be used to help them determine what they will work on in the next iteration. Story pointing is another tool that helps teams communicate and ensure there is a common understanding of what needs to be done to implement the story.

Once the team is ready to implement a story and the details are understood, it is typically split into smaller tasks with time-based estimates, typically in hours.

Task Boards

A task board is an agile technique that creates a visual representation of the work a team is doing. When used in agile development, its most common use is to track the status of tasks needed to complete a user story.

At its most basic level, a task board would have these three columns: To Do, Work in Process and Done. When used to for Scrum sprints, the first column would have the stories in the sprint backlog, and then all the tasks associated with that story would start in the “To Do" column as sticky notes.

Each day, the team would move any tasks that they were working on to the “Work in Process" column, and on to the “Done" column when it was completed.

There are many variants in the way teams use task boards and they may create other columns for test or maintenance tasks. A task board may be a physical white board that has been split into rows and columns with tape, or it might be an electronic board allowing remote team members access.