Release planning that survives contact with reality.

Key agile release planning information.

Below is a taste of CodeStringers’ expertise in agile release planning and development. For more on the types of agile methodology, check out our blog post.

• User Stories
• Story Point Estimation
• Velocity & Release Estimation

What’s a User Story?

A user story is the definition of a software feature to be built. User stories have a specific format that includes four fields (three illustrated in the picture above):

• Who is the user persona for the feature?
• What does that user persona want the software to do?
• What goal does the user persona have that the feature will achieve?
• The “Definition of Done” in the form of listed acceptance criteria.

The term “user persona” simply means a description of the prototypical user of the feature. Software products may have a single or multiple user personas.

The format of the story is:

• As a [user persona],
• I want to [what the user persona wants the software to do],
• So that [the objective the user persona wants to achieve].

Acceptance criteria are typically use cases. One use case is the “happy path”: what happens if the feature works as expected. The others are “negative use cases”: what happens when the software doesn’t do what the user wants. For example, take a “login” feature:

• The happy path is that the user inputs a username/email address and a passsword and gains access to gated functionality.
• Negative use cases are what happens when the username/email is bad; the password is bad; both are bad; in the case of a mobile app, what happens when there’s no connectivity.

Well written user stories meet six criteria articulated as the acronym “INVEST”:

• INDEPENDENT: Each story must not have functionality that overlaps others. Login is independent of password reset, for example.
• NEGOTIABLE: Perhaps the most forced word in this acronym, “negotiable” simply means that the team can understand the story and acceptance criteria.
• VALUABLE: Each story creates value for the customer.
• ESTIMATABLE: The team can size the effort to deliver the story.
• SMALL: Stories are small enough to be completed in one sprint, perhaps even smaller. Some organizations dictate that stories must take less than a few days. Stories that are too large are often too complex and need to be “broken down”.
• TESTIBLE: The acceptance criteria for the story can easily be translated into test cases, eaching having an expected result. When tested, if the expected result does not occur, a defect exists. The story is not “done” until all defects are cleared.

Estimating User Stories.

Estimation of user stories is done by assigning a numeric value to each story called “story points”. Story points are an abstract concept but an important one in terms of the psychology of a development team.

Prior to Agile / Scrum, development team members were all asked to provide estimates in time for everything they did. This was often referred to as “man-hours”. The problem is that each feature built could involve multiple team members, each one having to provide an estimate. Consider building a web application. You have a UX/I designer, a frontend web developer, a backend API/service developer, a database architect, a manual quality assurance tester, and a test automation engineer. Each one must complete work for a given feature to meet the acceptance criteria.

How much time would it take to get estimates from each team member so that you know the total effort? How do you know if those estimates are accurate? What culture does it create when team members give estimates that are wrong (low) and are later criticized for the inaccuracy?

Enter the Story Point.

Story points are a numeric value that the team collectively assigns to each story in the backlog and does so using “relative” estimation. Rather than each individual answering the question, “how many hours will this take?”, the team together is asked, “what stories that we built historically is this larger than and which ones is it smaller than?’

Most development organizations use Fibonnacci numbers as their story point values: 1, 2, 3, 5, 8, 13, 21, 34 and so on.

So, how does it work?

The team looks at a given story and realizes it is larger in effort than one story built recently and smaller than another. The first of those took 13 points. The latter took 5 points. So, the estiamte for this story is 8 points. And move onto the next story.

Why is this method valuable?

#1 – Speed. Ask people for time estimates and they’ll spend time trying to make sure they’re not low in their estimate.

#2 – Less Sandbagging.

Ask people for time estimates and they’ll likely estimate high on purpose because it’s better to “under-promise and over-deliver”. Problem is that this may get to the point that estimates are so high they are of no value. Worse, once people are told that an estimate is accepted, they may find ways to actually use all of the time they’ve been given to deliver (i.e. they don’t work hard).

#3 – Culture.

Asking individuals for estimates creates a individualism culture, which is the fastest path to a low productivity product organization possible. As the saying goes, “There is no ‘I’ in TEAM.” When you ask teams to estimate together, no one person feels politically exposed. If the team is wrong, we learn from it. In the case where a person is wrong, blame is assigned.

Velocity Explained. The term “velocity” refers to a unit of measurement in Scrum that illustrates the average number of story points completed in sprints. It is hugely important for a few reasons:

#1 – Planning Future Sprints.

It’s important to plan sprints such that the volume of points planned is slightly higher than velocity. Why? Because you always want your team to have goals that push them to increase velocity but not so much greater than velocity that the team feels defeated.

#2 – Release Estimation.

Scrum as a methodology does not discuss release planning, but the reality is that few if any product versions only require one sprint to complete. Releases typically include multiple sprints.

Businesses need predictability. How do you plan sales and marketing activities if you have no idea when a product version will be released? How do you forecast revenue and profitability? You don’t.

As such, velocity allows teams to estimate product version release dates early in the release development. Here’s how it works.

The team completes a few sprints to establish a velocity of 50 points (per one-week sprint). The team then estimates everything remaining in the product backlog (for that product version) to sum to 2,000 story points. Divide the sum of the backlog estimates by the velocity: 2,000 / 50 = 40 sprints/weeks.

Now decisions can be made. If the organization needs the release in 30 weeks, it may be possible to add resources to increase velocity. Moreover, the organization can now track progress sprint-by-sprint to ensure that the team continues to track to the release date and adjust as needed. No surprises at the end of a cycle.