Günther Gerlach

written by gunther gerlach-2009

Define your Sprint duration: A Sprint is a key when agile scrum process is implemented in SDLC. The Sprint defines the amount of time where a team will release a feature or list of features from a giving sprint backlog. This is an important decision. Scrum suggests 30 days, but they could a week if you estimate that will improve your team efficiency. The optimum Sprint duration depends on many factors. I suggest going back to your team and analyzing the perfect duration to be able of releasing a piece of software. I suggest 14 days, plus a planning day for your team and Stake Holders to create the product backlog prioritize requirements form different teams and, analyze the product burn chart. This will leave 2 weeks of intensive work and also, two Sprints a month.

For fast-moving products or markets, such as web-based products - where there is central deployment and no rollout or user training - 1 month seems like a lifetime! Personally I like 2 week Sprints for fast moving products.

Sprint Duration must be Consistent: Whatever Sprint duration you choose to go for, keep it consistent. This, in fact, is more important than the length itself. This makes your process repeatable and consistent with other process improvement methodologies like Lean. This consistency that allows you to start understanding how many Product Backlog points you can typically do in a Sprint.

Select Target Backlog for Sprint: After you have decided on your Sprint duration, you must decide the goal for the current Sprint. Look in your product backlog and select your target backlog for the Sprint. Make this decision as a team. It is recommendable to include more than you think can be achieved. It’s important to prepare more items during planning in case the team finishes early. These items can be clearly identified as stretch tasks and the Product Owner should not expect them to be completed. These are the things you will only do if the Sprint goes better than you expected. This decision is easy to make having your Scrum team’s previous project Velocity chart (Velocity is the number of Product Backlog Points delivered in a Sprint).

Clarify Sprint Requirements: Take each item on the Product Backlog. It’s important to go through them methodically, one item at a time. The Product Owner presents each item and explains how he/she sees it working from a functional perspective.  The whole team discusses the item in detail. The whole team asks questions about the feature in order to establish what it should do and how it should work. The outcomes of this discussion should be captured on a whiteboard or flipchart, or someone could write notes on a laptop as the discussion progresses. Interactive or printable whiteboards are ideal for this process. But the important principle in Scrum, and in any agile scrum development methodology, is that you write requirements feature by feature, just before they are developed.

Write requirements in a way that is lightweight and visual. Agile requirements should be barely sufficient. The fact the features will be developed and tested within the next few weeks, and by the team that were present, makes this possible. Consider writing ‘User Stories’, a concept from XP (extreme programming). Check my post about User Stories if you need more information about it. But the basic concept is to write features using this construct: As a [type of user], I want to [do whatever], so I can [achieve what goal].

The story can be backed up by a sketch of the UI, a wireframe or visuals. Annotate the sketch to describe the functionality. Backed it up with statements about how it will be confirmed (or tested). This will help to identify scenarios up front, before it’s developed.

The Process: The way to implement Scrum and track your results is simple.

example: The following is a perfect example of a User Story that I found in Internet.

Confirmation: Writing tests up-front helps to ensure the software is designed to pass. Writing tests up-front also helps to identify scenarios that users, developers and/or analysts may not have thought of. Keeping User Stories small enough to fit on a card helps to ensure that requirements are broken into small, manageable pieces of functionality, i.e. individual features.

Cards also work nicely in conjunction with whiteboards, providing clear visibility of progress and enabling team collaboration, moving cards around the board as things progress.

Gunther Gerlach