-2

Scrum uses velocity as a metric. How do we increase velocity in scrum

4
  • 2
    Hi Vinusha, welcome. The question shows little to no effort. Have you done any research? What exactly you didn't understand from it? Feb 23, 2020 at 15:01
  • 2
    Ummm... work faster? Feb 23, 2020 at 19:46
  • Your question needs to elaborate on what you are trying to achieve (By increasing the team's velocity). Trying to increase velocity can do more harm than good. If the team simply bloats the size of user stories being estimated, their velocity could double (or be anything that the team needs it to be). Remember that scrum emphasizes on the team being able to keep a sustainable pace indefinitely than trying to overwork and wear out. Feb 25, 2020 at 7:24
  • This is an X/Y problem, and closely related to this one.
    – Todd A. Jacobs
    Mar 7, 2020 at 15:25

2 Answers 2

2

Velocity is a metric as you already noted, a tool to help estimate how much work your team can realistically finish within a sprint. It's not a goal number! See https://en.m.wikipedia.org/wiki/Goodhart%27s_law for an explanation why making metrics into goals is a bad idea.

I suspect that the question behind your question is how to increase productivity. Scrum works from the assumption that developers inherently want to perform well and has several mechanisms to support this goal.

  • Identify impediments, and have a dedicated role (the scrum master) to deal with them. Productivity is often improved not by working faster, but by not wasting time on unproductive things. The goal here is to deal with external causes of reduced productivity.
  • Improve your process through retrospectives (inspect and adapt.) This is the task of the team as a whole, they know best where the weak spots in their process are.

Of course you need to realize that productivity can't be monotonically increased. Reliability and repeatability are goals that are at least as important in getting a working and satisfying solution out to the customer.

0

Here are some very basic and general tips to improve productivity

As others pointed out in the comments, velocity is a relative measure that could vary from one team to another.

  • Requirement clarity: If your developers are often waiting for clarifications during the sprint, make sure all requirements and acceptance criteria are fully known latest at the time of sprint planning. Otherwise, don't include that story in that sprint.
  • Context-switching: If developers are wasting time and effort in context-switching, the Product Owner (PO) should set the priority at the time of Sprint Planning and no one should be allowed to change that during the sprint.
  • Impediments: If your developers are often delayed by impediments, the Scrum Master (SM) should focus on removing / preventing impediments. Organizational impediments (such as creating a ticket to get the Sys Admin to grant access) are often well known but hardest to tackle.
  • Cross-functional: If your development team has people with single skills (For example, designers will do only design) then there will be a lot of idle time. Designers will be busy in the first part, developers will be busy in the middle and testers will be busy at the end of the sprint. So, push your team to be cross-functional.

Also, as others have pointed out in the comments, ask a more detailed question stating what steps you have tried and what is not working.

Not the answer you're looking for? Browse other questions tagged or ask your own question.