Sprint Velocity

The most important measure that an Agile team will use in planning is its “Velocity”. It is the amount of work finished by the team in each sprint. It helps the team to identify how much progress they can aim to make in a given sprint. Velocity is calculated by adding all the story points given to each user story that is completed by the end of the sprint. It measures output, but not the outcome.

The steps involved in Velocity-based Sprint Planning are as follows:

• Calculate the team’s average velocity (from last 3 Sprints)

• Select the items from the product backlog equal to the average velocity

• Verify whether the tasks associated with the selected user stories are appropriate for the particular sprint

• Estimate the tasks and check if the total work is consistent with past sprints

How to calculate the sprint velocity?

Velocity is calculated at the end of the Sprint by totalling the Points for all fully completed User Stories. The partially completed user stories are NOT taken into consideration for Velocity calculations.

Responsible Entity: - Scrum Master

The expectation from Responsible Entity

• Facilitates sprint planning in order to ensure that the discussion is effective and unbiased. The decision of old-timers in the project should not impact people who are a novice in team

• Assure that there is active participation from all the team members.

• There is an agreement to the sprint goal and that the appropriate product backlog items are included in the sprint backlog.

• Felicitate the sprint planning using planning poker (Fibonacci series )

• Most likely the team is working in a distributed mode then a planning poker tool can be used, the link for the same is here.

If all the team members in a team are new to Agile way of working and are not well acquainted with story pointing technique, then it’s always suggested to follow bottom-up approach i.e discuss the list of activities (task ) required to complete the US, give estimates in terms of hours, sum up the hours and then put in the story points.

Once the story points are discussed and finalized, it is the responsibility of the Scrum Master to assign the story points to the respective user story in JIRA.The corresponding tasks to the user story are discussed and are created in JIRA by respective team members. Suggested task is Development task ( note that this would include the implementation and the unit, integration tests )

• QA – Test Case Creation Task

• QA – Test Case Execution

• Dev – Code Review

• Dev - UTC

• Deployment onto test environment for QA to test note:-

It’s always advisable to break tasks if, estimated time for completing the task is more than 7 hours.

It’s always good to have a nomenclature for the creation of a Task.

Example-

The subtasks can be -

All the tasks have to be linked to User Story at the end of the Sprint Planning sessions, the two artifacts that would be ready are Sprint Goal and Sprint Backlog.

Note: Many times, the business and competition demand last-minute priority work to be picked when you start the Sprint. This is fine as long as it’s minimal.

Advisable best practice

• PO shouldn’t be telling how much work the team should be picking. The team should take a wise decision by looking at previous sprint velocity. The idea is to have sprint success and continuous improvement.

• Always keep a little buffer for planning next sprint items, unknowns in existing sprints, and tech debts.

• A lot of teams prefer to keep 20% time aside to deal with tech debts. This may be a good idea while it’s always suggested the team to plan for this 20% during sprint planning and grooming only. What you plan is what can be accomplished.

• Don’t be very aggressive as the quality of software in most cases is more important over quantity.

• The team member shouldn’t be picking up multiple stories in advance. Each and every member should pick one story and once done they should move to the next one as per the priority order specified in Sprint. The exception of picking up the items within Sprint should be ok as long as the PO is good with that.

• Always create a task for stories. Don’t just include tasks that have business values while do consider tasks related to development and testing. For instance testing, code reviews, writing tests, etc. Keep in mind, don’t write too many tasks.

• Try to break down the story to as small as possible while if the estimation is going beyond then it’s important to divide that into smaller stories. There are instances where you can’t break down the story to the level where you are not getting business value out of it which is OK at times but do avoid this situation as much as possible.

• There could be scenarios for a story, where lots of research is involved and there are unknowns that need to be unearthed, prefer to go with Spike.

• Trust each other and support each other. The best output for a sprint is achieved when everyone works together as a team.

• Pair programming is strongly encouraged at Knoldus. Generally, two people do not work on the same task in series unless absolutely necessary. It is observed, with the offshore-onshore model, the story is being worked on one story offshore, and further, it is handed off to another team member onshore. These cycles keep repeating. The amount of productivity Loss that happens in this approach is not worth it.

Important Tip – The scope creep can be managed within Sprint with only two ways-

1. Refuse new work in the middle of Sprint and take up that in the next Sprint.

2. If it’s absolutely mandatory to pick the work in the middle, you need to take out an equal amount of work from Sprint. Use can use MoSCoW rule to do it. While planning a sprint label user stories as must have, should have, could have and wont have. If priority task needs to be adjusted equal amount of wont have user stories can be swapped out of the sprint.

At times, if teams are done with Sprint in advance, in that case, the team can pick more work while it is always better idea to increase your velocity and focus on tech debts, testing, and quality practices. The team can even spend time on learning which is usually way more important than we usually think.