Scrum is an iterative process that demands a fully tested, shippable version of the software every 3 to 4 weeks. These deliveries occur at set times at the end of each Sprint. Sprints will occur whenever there is still work defined in the Product Backlog.
Kelteca are Scrum certified


A time-box of 3 to 4 weeks during which the Scrum team tries to achieve a Sprint Goal. At the end of the Sprint, the team must deliver code that could potentially be deployed to a production environment.


A prioritized list of the project's unimplemented functional or technical requirements. Can be thought of as the project's to-do list. Single items in the backlog must be small enough to complete by the Team during a single Sprint.

The Product Backlog is created and maintained by the Product Owner and Scrum Team, and it evolves throughout development as product requirements change. New items can be added to the Product Backlog if the Product Owner determines that there is a new requirement before final delivery. Items in the backlog should be prioritized such that the most critical items are at the top of the list.


Responsible for helping to create, and prioritizing the Product Backlog.


Self-organizing teams ranging in size between 5 and 9 people who are responsible for all the actual work in Scrum. All members are held equally responsible for the project's success or failure and should therefore be fully committed to the project and each other.

Once the project's starting Product Backlog is created, a Sprint Planning Meeting is run to determine the Sprint Goal as well as the items will be placed on the first Sprint Backlog. The selected Product Backlog items should be those that are most critical, and which help satisfy the Sprint Goal.


A two-part meeting that occurs before every sprint. The Product Owner and team decide the Sprint goals for the following iteration, and the Product Backlog Items that should be implemented to satisfy those goals. Then, the team breaks down the selected Product Backlog items into Sprint Backlog items what they will implement in the following iteration. The first and second parts of the meeting should not take more than 4 hours each.


A statement succinctly defining what the team is trying to achieve during the Sprint. Examples would be 'allow entry of administration data' or 'improve load test performance by 50%'.


The list of tasks that will be completed during the sprint. Items on this backlog should require between 4 and 16 hours to complete (assuming an 8 hour work day).

Once this is accomplished, the Team begins development and testing. Because the Sprint Teams are self organizing, they alone decide which tasks from the Sprint Backlog each member will work on.
Every day, the Scrum Master and the Team meet for a Daily Scrum. It is the Scrum Master's responsibility to remove any impediments that the team raises during these meetings. He should also insure that Team Members are updating the effort remaining estimates on the Sprint Backlog as they continue with their work.


The Scrum master is responsible for facilitating the Scrum process throughout the life of development. Additionally, he/she is responsible for removing any impediments preventing other team members from making process.


A daily meeting during which all team members simply answer the following three questions:

  • What did you do yesterday?
  • What will you do today?
  • What impediments stood in your way?

The meeting should never last more than 15 minutes, regardless of the number of team members. It is important to note that while any interested party may attend the Daily Scrum, only members of the Team and the Scrum Master may speak.

Using these time estimates, the Scrum Master should create one or more Burndown Charts to visually illustrate how much effort is remaining for the current Sprint as well as the Product as a whole.

During the Sprint, if unanticipated tasks surface they can be added to either the Sprint Backlog or the Product Backlog. Additionally, it is possible to remove items from the Sprint Backlog to ensure delivery on the planned date. The removed items should not, however, impact the team's ability to achieve the stated Sprint Goal.

If the team finds itself with no items on the Sprint Backlog with time remaining before delivery, additional Product Backlog items should be decomposed and added to the Sprint Backlog.

In the rare event a team cannot achieve their Sprint Goal, the Scrum Master should cancel the Sprint with an Abnormal Termination. This should be viewed as a serious failure of the team, and should not happen lightly.


chart01.jpg, 8,3kB A chart which shows the remaining effort required (opposed to the spent effort) for the items on the current Sprint or Product Backlog.

The following are two examples for a Product Backlog Burndown. The Y access represents effort remaining on the Product Backlog after the completion of the Sprint. The X access stores the Sprint number.

chart02.jpg, 7,2kB

Sprint Burn down charts show how much effort is remaining for the current Sprint. They are similar to product burn down charts, but have date along the X axis instead of iteration.

chart03.jpg, 13kB

When the Sprint ends, two separate meetings take place: the Sprint Review and Sprint Retrospective. These meetings give the team a chance to show off the work they accomplished to all interested parties, as well as reflect on their work and adapt their efforts for the next sprint.

The next iteration then begins with a Sprint Planning Meeting and continues until there are no more items on the Product Backlog or until the Product Owner decides that the most recent release satisfies her expectations.


A maximum 3 hour long meeting held after the Sprint Review during which the Scrum Master and Team discuss the positives and negatives of the previous Sprint and how to improve the next Sprint. This meeting is where team members can air any complaints they have about the process, team members, or even the Scrum Master.