3

So I know that this question has been asked before, but since I haven't really seen anything that benefited my problem, I thought I would give it a chance.

So first things first, in a perfect world we would be completing sprints and at the end of every sprint, we will deliver all the story points that we have committed to. I know that it is not always attainable, so a 90% delivery to me is still acceptable.

The problem I am facing at the moment, is that we commit to (For arguments sake) 100 story points, but only complete 20. This becomes a nightmare as trying to manage the client becomes almost impossible. Now the logical thing to say here is that we are over committing each sprint or underestimating stories which is very possible.

Just to explain the process, maybe I am missing something,

  • We have 2 week sprints
  • During sprint, product team gets requests from the client and do requirements gathering, running details past the team/tech lead prior to prioritizing the backlog (We don't have a dedicated grooming session, however stories are fleshed out properly prior planning 1)
  • Thursdays of every second week, we do planning 1. This session is run by the product team, we try to estimate as much of the stories on the backlog as possible, backlog is ordered based on the current priority.
  • Fridays of every second week, we do planning 2. This session is run by the Team lead, expectation is that the team took some time between session 1 and 2 to go through work required in order to adjust estimations, but we go into more technical detail of the change required
  • Planning 1 is for initial estimations, this can change during the planning 2 session
  • The team is left for 2 weeks, there are cases where scope creep occurs, however try to limit it as much as possible as we have a dedicated Developer to work on production issues that is not part of sprint work

The problems I am facing are the following,

  • Team does not communicate that they will not make sprint deadlines
  • Team seems to not fully understand the features that are requested (Could speak to lack in requirements, however I don't fully think so)
  • Team takes too long to develop features, going over the expected delivery estimation.
  • Team does not take the initiative to go through future stories during the gap between planning 1 and 2

I know that this is a very common issue in software development, however it is an extremely frustrating one as you struggle to build confidence with your client if you cannot deliver on time. Just to give context on myself, as that might have a direct influence. I am currently the SDM for multiple teams, due to a bit of a lack of technical understanding (Team/Tech lead) in some teams, I am quite involved with some planning sessions. I come from a senior developer background, have been developing software for about 10 years.

Team in question, can differ in size, but 10 Developers, 3 QA, 2 Product, 2 Team Leads.

Sorry if this is a duplicate question, I have checked the other questions and answers and thought it made more sense to post a new question.

  • 2
    You're doing Scrum? What's the Scrum Master's job in your organization? Playing Minesweeper? After the first failed sprint, the immediate task of the whole team including the Scrum Master is to find out what went wrong and what to change to make the next sprint a success. – Hans-Martin Mosner May 18 at 12:40
  • So we do not have a dedicated Scrum Master in the organization unfortunately, however we do that as part of our retro sessions, we sit down go through what went wrong and try to adjust. However it seems that those adjustments are not really working. By this I mean that, we have committed to 100 points, delivered 80 for example, so reduce next sprint to 80 just to make 60. – user40680 May 18 at 13:03
  • 2
    The goal of a Sprint is to complete the Sprint Goal, not to "complete 90%+ of your story points." I think you have coherence and collaboration problems more than anything else. – Todd A. Jacobs May 18 at 19:33
  • @Todd, yes 100% but I am also aware that it is the "best case scenario" I would prefer to complete all sprint goals, but there are lots of factors hence I made that statement :) – user40680 May 19 at 6:42
3

The purpose of Sprints is not to deliver points, but rather to deliver value. The team doesn't commit to delivering a certain set of points or a set of Product Backlog Items. Instead, the team forecasts how much work they can accomplish as part of Sprint Planning. Throughout the Sprint, the team should be focusing on achieving the Sprint Goal, rather than completing a particular body of work or finishing so many points or some other measure of output.

Looking at the specific practices, I can see several potential problems or opportunities for improvement.

Your refinement process seems lacking. Recent revisions of the Scrum Guide suggest that about 10% of the Development Team's capacity should be allocated for Product Backlog Refinement. If you have a Development Team of 3 people and a standard 40-hour workweek, I would expect about 12 hours per week allocated to refinement. There's no defined method for performing refinement. Some of the teams I've worked with had everyone get together a few times a week. Others had people work individually on refinement and then get together for about an hour or so a week to align. The team needs to figure out what works for them, but it is important that it is a full-team activity to get the knowledge spread out and get the whole team to buy-in to the work being done.

I believe that the poor refinement is leading to a number of the problems described, including not fully understanding the features they are being asked to built and taking too long to develop the features. It's highly likely that the lack of understanding is leading to longer development times.

The "Planning 1" and "Planning 2" is not clear to me. Sprint Planning is a single session. There are two aspects to it - the first is determining what to build based on forecasting and the second aspect is determining how to build it. More specifically, the primary outcomes for the first part of Sprint Planning is a Sprint Goal and the outcome for the second part is a plan to achieve that Sprint Goal.

The team size and composition may also be issues.

Although Scrum doesn't enforce rules on a minimum or maximum team size, Scrum is most effective with a Development Team size of between 3 and 9. You have 13, maybe 15 (depending on if the Team Leads are part of the Development Team). That feels very large and communication gets difficult with that many people.

I'd also point out that Scrum doesn't recognize a "team lead". Such a concept tends to lead to work being pushed onto the people doing the work rather than being pulled into a Sprint and then into development. It also doesn't promote self-organizing teams.

There's no mention of the Daily Scrum or the Sprint Retrospective, but I'd suspect two things. First, with such a large team, you aren't able to effectively hold a Daily Scrum in a reasonable timebox. Second, many of these issues may come out in a well-run Sprint Retrospective.

The biggest issue that I see is poor communication. The team size and lack of constant collaboration are probably the two biggest drivers.

| improve this answer | |
  • Thanks for the feedback :) So yes we do daily scrums, timeboxed to about 15minutes due to the size of the team, and at the end of the sprint we do retrospectives. From what I can see here, the size of the team does signify I problem and something I want to look at. The different planning sessions can more specifically called grooming vs planning I guess, but I do see your point mentioned above. Appreciate the feedback :) – user40680 May 19 at 6:58
2

It sounds like you are dealing with a large team and I get the impression that you are doing scrum, or elements of it. If this is not the case you can probably disregard the rest of this post.

Given the problems you describe I would suggest you break your large team into several smaller teams which work off the same backlog. It's a big organisational change, so not one to take lightly, but it's advice I would give to most in this situation. Small teams can be nimble and react quicker.

Some observations from the info you provided:

  • It sounds like you may wish to at least review accountability/responsibilities in your dev team/organization. Who's held accountable for the delivery of the team output? What's the responsibilities of the team lead(s) and the other members?

  • It sounds like the team is not feeling fully responsible for their work and output. What about each individual team member? How are they feeling about the situation? What do they attribute this "failure" to?

  • Having fewer members may help identify any underlying issues that do not surface in your current constellation. Is each individual member working at full capacity or struggling with recurring issues?

  • Having fewer team members in a group may help empowering the group, making them more efficient.

Consider if 1 lead + 2 devs + 1 QA + 1 PO could form a team. Do you see any reasons why this would not work? Are your stories / backlog ready for it? Is your code repository ready for it?

If the above could work, can you create three of these constellations with the current team members? Is there enough domain knowledge in each team? Don't worry if one or two people need to bridge two teams. This can be overcome with hiring or re-config later if you feel you're on the right track.

Ask them to take on fewer stories and try to finish a couple of sprints. Establish velocity for each team. Only then take on more stories.

Best of luck regardless of measures you choose to implement.

| improve this answer | |
  • Honestly a very interesting concept, I haven't really thought about breaking the team up into smaller teams, purely because they form the team for a particular project set. I have come to the team on various occasions to try and identify what they could see as potential problems, but had no success. My honest opinion has been that they don't see a sprint delivery as a deadline. The one problem I would face here is product knowledge, even though we have documentation and knowledge sharing sessions, i believe these are mute as the team still struggle with shared concepts. – user40680 May 18 at 13:27
  • The guys also do struggle with recurring problems. To give a crude but practical example, a web page that I have written in the past took me 1 week to complete, the same page with a new framework and design (No new functional changes i.e. the backend remains unchanged) took a developer in the team 6 weeks to complete. – user40680 May 18 at 13:28
  • You deliver the same page twice? Doing it a second time would mean reusing the first one. – Joris Van Regemortel May 18 at 13:31
  • @Joris, so context on the above we are busing doing a new redesign, hence the same page being delivered again. The new iteration is about 1.5 years from the first delivery, The client has requested that we do a redesign of the current production website. The first page was developed in Angular 5 and the new one in Vue – user40680 May 18 at 14:05
1

I expect your team could benefit from some coaching/mentoring since there seem to be some complex issues that they aren't really taking ownership of.

Some observations. You mention a total of 15 people, which is unusually large for a Scrum team. Split into multiple teams and keep it to less than 10 per team. What role are the team leads playing? There is no "lead" in Scrum but the fact that you are asking this question suggests they aren't being very effective leads either. Why plan for the next sprint during week 2 of the current sprint? That seems counter-productive because it is diverting the team at a critical time. Do planning on day 1 of each sprint and leave it at that.

Since they struggle to estimate two weeks of work it may be worth shortening sprints to one week. That could ease the estimation difficulties a little, reduce unexpected scope changes and the team will probably benefit from the discipline needed for short sprints. Also try going without points-based estimates for a while. The reason teams estimate is to work out what can fit into the sprint. Points don't seem to be working for them and maybe it's simpler just to ask them to pick the things they are sure they can do from the top of the backlog.

| improve this answer | |
  • A cool concept, the reason the team is this large is mostly due to how current business operates and priority. With regards to splitting into multiple teams, how would you suggest doing that? Split into a website/backend team or smaller teams that span both website and backend? So the planning session could move to the start of the next sprint, and something I would like to try. The reason it is done at the end of the current sprint is so that new sprint can immediately start on the following Monday. – user40680 May 18 at 14:08
  • We have tried to shortened the sprints, however probably not long enough as we didn't see much of an improvement. Some of our teams have had a lot more success changing from a point based system to hour based, so we are trying that now to see if that provides better estimation. We have attempted "Cherry picking" in sprint, however that ended up in certain tasks left for more "senior" developers which caused the situation where on standby, guys were not able to answer questions or fix problems with those components. – user40680 May 18 at 14:11
  • 1
    @user40680, if you split the team, each new team should be composed such that they can deliver the full functionality of a feature by themselves. Thus you should rather have "Product X team"/"Product Y team" or "Full product team 1"/"Full product team 2" than "frontend team"/"backend team". – Bart van Ingen Schenau May 19 at 9:01
1

These are very real problems that loads of people face.

I will try and give some advice/opinion (you dont have to take it) on your points

We have 2 week sprints – that’s a good start During sprint, product team gets requests from the client and do requirements gathering, running details past the team/tech lead prior to prioritizing the backlog (We don't have a dedicated grooming session, however stories are fleshed out properly prior planning 1) Thursdays of every second week, we do planning

So by you stating planning 1 I am assuming there is a planning 2, I would suggest to rename these to Backlog grooming and Sprint planning – both have different functions. In Backlog grooming you need to ensure the team have all the information in the tickets, they need to work through it together and not expect them to do things (like create their own stories etc – this is normally for very mature teams) – so make sure you have a definition of ready and a definition of done.

Have the PO work with them through every ticket and create the task/stories then when all the info is there have them estimate (now in the beginning this might take time but the more they do it the better they will get at it)

Re during sprints – this is a very fine line here, a sprint is a sprint you don’t put more work into a sprint if it has already started, you only stop a sprint once the sprint goal is obsolete, but I know In the real world things happen and we get P1s that are critical, normally address by 2 ways, if it is absolutely critical then stop the work (create a spike) and fix the issue then continue with the sprint – this might be confusing, other option is to have it wait to end of the sprint (but not normally the case as its mission critical) – communication to stakeholders etc is key here (but you also have the option to have a BAU squad that handles that kind of stuff.

This session is run by the product team, we try to estimate as much of the stories on the backlog as possible, backlog is ordered based on the current priority.

That’s perfect!

Fridays of every second week, we do planning

This session is run by the Team lead, expectation is that the team took some time between session 1 and 2 to go through work required in order to adjust estimations, but we go into more technical detail of the change required Planning 1 is for initial estimations, this can change during the planning 2 session The team is left for 2 weeks, there are cases where scope creep occurs, however try to limit it as much as possible as we have a dedicated Developer to work on production issues that is not part of sprint work

This to me sounds like a few mixed bags of issues, 1 the difference between planning sessions – this is a hard point but there is a PO for a reason and there is a delivery team for a reason, you need to use them for their strengths and roles 1. 1. A team needs to work together on the grooming session (planning 1) and work through the estimations as a team – there shouldn’t be more expectation on the team other than delivering the item if it meets the definition of done. – a grooming session can take to 4 hours (time box it) 2. 2. Only have standups as updates (teams need to focus on delivery and not be micromanaged) 3. 3. Scope creap is a silent killer, but should be managed in stories and enhancements not as just evolving the same ticket bigger 4. 4. There are more

The problems I am facing are the following:

Team does not communicate that they will not make sprint deadlines

This might be for a whole range of reasons, trust, transparency, taking chances, underestimation etc – now if the team lead is their manager that might introduce issues too as people don’t always open up to their team lead, even though they should and there should be a strong professional bond.

Recommendation is in grooming (planning) to break the stories small enough to track individually – have the team together decide the estimations work together and hold them accountable.

Team seems to not fully understand the features that are requested (Could speak to lack in requirements, however I don't fully think so)

Again would make sure 1. Team do grooming properly and that they estimate properly together (not individually but at the same time, then ask questions and see why people are thinking things are different) But I do agree there could be a lack of requirements or understanding of them

Team takes too long to develop features, going over the expected delivery estimation. Team does not take the initiative to go through future stories during the gap between planning 1 and 2

That again will bring me to grooming (should be the only session where you groom the backlog for future work – in your words it’s the Planning 1) - then planning (session 2) is where you take and plan work into your next sprint. Taking too long for estimation might mean that the story wasn’t properly sized/explained/worked through To me it seems like there is a lack in understanding, process and team work (not overall but sounds like this team just needs to get into a rhythm)

Looking at the team size, split them into 2 teams, it is too big for a single squad (recommendation is 7 +- 2) that way you can measure the teams individually and check on work etc as a team that large must be a challenge to manage

Re the team leads are they dedicated to the teams/squads? as if they are not shouldnt be involved in estimation etc :)

At some point when all the process etc is solved and they are still not performing you might need to look at individual performance but that should be last resort!

| improve this answer | |
  • awesome feedback! appreciate it, defintely keen to try some of the ideas pitched here. Currently we do have a split in BAU vs sprint, but like some the ideas here! – user40680 May 19 at 6:54
  • Good insights. However, italics might not be the best use to distinguish between quotes and comments. Since SE does have a quote formatting option, you might as well use that one. :) – Llewellyn May 19 at 18:48
0

Calculate the team's velocity by taking the average number of story points the team has managed to delivery in the past 3 sprints. Use the velocity as the team's capacity for future sprints.

By doing this you will have a realistic amount of work in each sprint and you will be able to provide a far more reliable estimate to your client.

Once you are doing a realistic amount of work in each sprint you can spend some time in the retrospectives resolving the other problems.

| improve this answer | |
-1

Another immediate thought is that you might wish to place "requirements gathering" and "determining what's needed to do those requirements" ahead of, or even in-between your sprints. Perhaps you have a couple of non-sprint days in between each sprint where you properly prepare for what the next sprint should be, using this to guide the team's selection of what to include. Give them "a full two-week sprint to accomplish" what they set out to accomplish. I've been developing software for (koff, koff ...) a long time now, and I really don't see how anyone could do all of these things that you describe "in two weeks." Forget, for a moment, exactly what The Scrum Guide says, and look for a different work-sequence that's more realistic for your case. Every organization is different, and it's okay.

| improve this answer | |
  • Very valid point, I am very open to changing process at this stage as something is definitely not working. Appreciate the advice :) – user40680 May 18 at 15:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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