You have a planned roadmap and a set of work items to be targeted for the first phase. So, where do you store all these work items? In agile, you have a space where you can store your plan—the Backlog. The product owner is responsible for maintaining the backlog. Based on the input from the users, customers, and stakeholders, the product owner lists the product requirements, prioritize the backlog, and decides which work items will be pushed to the upcoming sprints.

Based on the prioritized list of work items, the product owner, sprint owner, and the team meet up for the 'Sprint Planning Meeting'. They discuss the work items and decide the scope of work for that sprint.

The product owner prioritizes work items from the backlog.

A team usually choose 6-10 work items in a sprint and each member of the team is assigned a task.

The sprint owner picks the workable items from the prioritized list and assigns them to the team members.

Other work items are maintained in the backlog and moved to the upcoming sprints.

If Backlog is the brain of your Scrum project, Sprint is the heart that keeps your project active. It is the time-boxed duration (of up to four weeks), where the team delivers a product increment to the customer. Based on the feedback, the team builds the requirements and develops a quality product at the end of the project. The next sprint begins immediately after the previous sprint ends.

 

The following questions may arise after you have read the above definition of sprint:

 

At the end of every sprint, the team will obtain the average velocity using the estimation points that were defined for each work item. If the velocity is fluctuating between the sprints, then the team will change the duration of the sprint accordingly.

When running multiple sprints, the team decides whether the sprint cycle will be long or short. The greatest advantage of choosing a short sprint cycle is that you'll likely reduce the amount of time being spent on the feedback and making changes. In a long sprint cycle, there is more time to complete the work items. When comparing both, choosing a short sprint cycle works well for teams with more capacity to deliver the outcome on time.

 

Your one week sprint should look something like this:

Your two week sprint should look something like this:

Based on your schedule, you can conduct a retrospective meeting either on a Friday evening or Monday morning to discuss the feedback and enhancements. If you choose to work on the weekend, then you can choose those days for the review or retrospective meeting based on your convenience.

Since Agile emphasizes communication, after the sprint starts the team conducts a 'Daily Stand-up' meeting for no longer than fifteen minutes. This meeting is organized by the sprint owner who meets up with each member in the sprint and discusses the progress of the work. During this meeting the members can share their hurdles in completing their assigned work. The sprint owner comes up with solutions and helps the team members in delivering the target on time.

During the sprint process the development team will start working on the items assigned to them and mark the status of the work on the 'Board'. In traditional project management, we stick notes on our bulletin board so that everyone in the team knows the progress of the work. Scrum offers a Board view with three statuses, by default - To Do, In Progress, and Done. When the sprint first starts, all the work items are listed in the 'To Do' status. As the work progresses, each member in the team moves the work items to 'In Progress'. When the work is completed the items are moved to 'Done'.

 

Say goodbye to sticking notes on your billboard and use the scrum method to record the progress of your work.

  

While the items are pushed back and forth on your board, you can start tracking the progress using the default reports available in Agile.

You determine the effort of the work and add estimation points based on it. Using the estimation points, the burndown chart is plotted for tracking the progress of the sprint. This chart shows the remaining estimation points for each particular day and using this the team focuses more on the pending work items in the sprint. Learn More

A Burnup chart is the reverse of a Burndown chart. This chart tracks the completed estimation points for each particular day. This helps the team determine the number of items they can complete in a single day. Learn More

A Cumulative Flow Diagram (CFD) determines the progress of the statuses in the Board. Using the CFD, your team can track the number of items in each status and determine which status requires more attention. Learn More

During this process you easily find out the progress of the sprint. As the sprint reaches its end date, the team meets for the 'Sprint Review' meeting. The product owner, sprint owner, and the team discusses the positives and negatives in the sprint. During this meeting, the team views the Velocity chart.

Velocity is the measure of how much effort the team delivers to complete the work. The performance of the team is determined using the velocity. Planned estimation points and completed estimation points are compared to obtain the average velocity.

 

 

When the sprint hits the end date, it's time to deliver the product to the customers. A workable software is delivered to the users. This is the feedback mechanism where the user will share comments, suggestions, what worked, and what didn't. Using this feedback, the team organizes the 'Sprint Retrospective' meeting. In this meeting, the team jots down the feedback obtained from the customers and starts the next sprint.

 

During the next sprint the team adds the feedback obtained from the customers, includes new work items to their backlog, and creates a new sprint. The same cycle is started again and the team implements the feedback from the last sprint.