Team needs a lot of time to deliver even the simplest stories- how to know why?

Question

So, the problem, from the management perspective is that a Scrum Team delivers only the simplest stories within the whole Sprint. Literally, changing a button takes two weeks. The Team estimates within a stable velocity, and mostly delivers everything that they commit to successfully.

I (a Scrum Master) have many suspicions why that is so, however I'd like to hear these problems directly from the Development Team. Do you have any tips on how to tackle this problem? What retrospective activities should I prepare for the Team?

To clarify: I'm more than sure that the problem lies within the development process rather than an overall unwillingness to work.

Answer 1

...a lot of time to deliver even the simplest stories

Only the development team knows what constitutes a simple story.

The time it takes to deliver a story depends on a lot of factors, including:

• The quality of the existing codebase
• Operational constraints, such as organisation standards, etc.
• How high the quality target is
• Non-functional requirements such as performance, responsiveness, etc.
• How much control the team has over design and architecture

As a Scrum Master I would be very careful about second-guessing the capacity of the delivery team. Instead I would be looking for issues to be raised by the team in retrospectives.

If they are not raising impediments then it may be they are not constrained. Alternatively, they may feel that some impediments are not solvable or there are other reasons why impediments can't be discussed.

My suggestion would be to organise a retrospective where the team categorises all impediments according to:

• If we had infinite amount of time, what impediments would we resolve?
• If we had better skills or capability, what impediments would we address?
• If we could tell the organisation outside the team to fix something, what would it be?

Make it clear that absolutely everything is in scope for the discussion. Also, make it fun by talking about an 'dream scenario' where they have the power to do whatever they want to make things better.

Do not set the scene by talking about the team under-delivering. This is likely to make them defensive. Instead, focus on making the retrospective positive and empowering for the team.

Answer 2

I think that you are right & you need to ask the development team for advice.

It could be that what is delivered is all the team is capable of - but I guess that is not what you think. So for some reason you think the team velocity is too low & you could be right but before anyone blow's a fuse I'll put a quote at the end to demonstrate why velocity can be wrong.

To solve the problem, firstly, you could have the next sprint(s) solely focused on this question. You will need to speak to the product owner but I'm sure they will be keen to get more work delivered so this approach may quickly pay for itself. So have the next sprint focused on improving velocity & ask the developers how this can be achieved. Don't try to tell the developers what to do, ask them what can be done. You may be surprised at the outcome.

It could be that the continuous integration/deployment processes take too long or that QA has a backlog or the team were once told that velocity when it settles down should always be the same - any number of reasons.

From Mike Cohn's book on 'Agile Estimating & Planning' he makes the following point to illustrate why if you plan too far in advance & use ideal days you could be measuring velocity wrongly in the chapter 'Choosing between story points & ideal days' (don't know your setup so this is for information):

"An estimate in ideal days can change based on the team's experience with the technology, the domain, and themselves, among other factors. To see why, suppose a programmer is learning a new language and is asked how long it will take to program a small application. His answer may be five days. Now jump forward a few months and ask the same programmer how long it will take to develop an application that is exactly the same size and complexity. His answer may be one day because he has become more skilled in the language. We have a [relative] problem now ... we would like to think that measuring velocity over time would correct or account for this problem. It won't. "

Ask the developers they will have the answer.

Answer 3

I've worked with some complex systems and workflows which required multiple levels of sign-off for even adding the simplest of features - e.g. a Refresh button within the application.

Having some understanding of the complexity will allow you to see where the delays or inefficiencies are - if indeed there are any. It's quite possible that the teams' work is being broken down along silo boundaries and getting sign-off for each silo is what is slow.

There are some questions I'd ask the team:

1. How could we break down User Stories in a way which means that we can deliver more value per Story for a similar cost?
2. What changes could we make to our work style or team setup to expedite/optimise the slowest parts of the process?

Answer 4

My initial thoughts:

1. The product owner should be working with the team to put highest value items at the top of the backlog. Is this happening? If not, the scrum master (you) should be coaching the product owner to manage the backlog so the team does the most important work first.
2. As the scrum master, you should focus a retrospective meeting around the topic of how to deliver more over the long run. I would suggest a brainstorming meeting, perhaps a lean coffee format, and ask them to brainstorm two things. a. what they can change that's within the teams control. What they would change if they could change anything in the company or organization. If you ask the team, they will most likely tell you. Just be prepared to help them act upon the recommendations and get support from "the management" ahead of time.

Answer 5

I agree with "ask the development team", but I would ask "Do you think we can increase our velocity? If so, how?" rather than "why does it take so long to deliver a simple story".

Also, this is a good article with a fabulous diagram that could frame a discussion about increasing velocity.