Sprint

The unit of iteration

Sprint

Armed with the release backlog you now determine estimates of time durations for each feature and how they should be prioritized. Once you have estimates for all the features, you’ll have an summary of the total time required to complete your work.

Next step is developing your sprints . Sprints are short duration milestones allowing the team to address a manageable amount of the project at hand, and progress towards completion for the planned launch.

Sprint Durations

The amount of time required really depends on the product release cycles. That said, sprints can range from 2-3 days and up to 25-30 days. Two-week sprint durations (10 business days) is the de facto standard. Why? It allows a team to have some creativity, and provides a near-term deadline that kills procrastination and forces members challenges to the surface.

Spring Backlog

Take the release backlog and split it into sprint backlogs. The best way to do that is by displaying the sprint backlog on a wall, ideally in the form of a task board.

A task board is oriented in rows and columns with each row containing a particular user story and one index card or sticky note for each task involved in that story. Task cards are organized in columns, minimally including “To Do” “In Process,” and “Done.” The team is able to see work progressing across the task board during the sprint and all work to be done is visible at all times.

Burndown Charts

How does one monitor progress? You use what is referenced as a burndown chart . The added value with the chart is that you get a visual glance regarding the status of your project instantly. With this visual, you can measure on a day-by-day basis, the work remaining for each sprint release. The trend you want to see the line moving is towards zero.

Burndown velocity

Viewing the burndown chart, you’re able to create the slope of the graph, what is referenced as the burndown velocity. Burndown velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. For example a teams rate of productivity might be that on a typical day they finish approximately 40 hours of work.