New answers tagged

1

Your boss also erred by telling the team that their product was going to be scrapped without apparently giving them the promise that they wouldn't be. Therefore, for what should be perfectly obvious reasons, the developers stopped caring about a product that the company no longer cares about, and put their job searches into high gear. Very soon you won't ...


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 ...


6

Stop Abusing Velocity I know it is not common for management to rely on velocity as a measure of productivity. But in this company, velocity and individual points are how teams and individuals are evaluated. So, you know the company is doing the wrong thing and following an anti-pattern, and yet you're expecting a different outcome. That isn't reasonable....


1

You should definitely be careful. Velocity is a subjective measurement. As teams stabilize, it usually reflects productivity with some degree of accuracy. However, it is not productivity and it can move independently of productivity. That said, it is possible that the team is right - their estimates are just more accurate now. If that is true, they may ...


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 ...


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 ...


-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 ...


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 ...


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,...


1

So... here is what I used to teach when I talked about Story Points in my CSM classes (I don’t talk about it in my CSMs anymore, unless under request). An estimate with story points carry a “confidence interval” around it - which means, its level of precision. And that’s THE reason why we use Fibonacci numbers. You see, we can imagine the estimate is ...


-1

With a highly interdependent system such as you describe, "stories" might not be sufficient either as a measuring tool or a task-layout tool. You need to incorporate an understanding ... no doubt provided by the experts in the team itself ... of how "stories" actually relate to the components of the underlying system. Because, "this is where the workers ...


0

Don't re-estimate the story points which have fallen out of the previous sprint, you're telling the team their commitment and points are not important and undermining the process. You need to get to the bottom of why. When you introduce this rule the team may say all the work is done which should lead to a conversation as to why the tasks were not fully ...


0

Sounds to me like your team wants to work, but doesn't want to solve, to plan or to be held accountable. Fairly common in my experience, generally a reaction to the presumption that management will hold the team accountable for negative outcomes, but not for positive outcomes. . . . [there] is a combinatorial explosion in the way they can be used such ...


4

There are so many things happening here that if you try to enumerate them, you'll just get frustrated, as I suspect you already are. Let's start with a simple acknowledgement that your team is not, in any way, practicing Scrum. They may be doing great work, but they aren't even trying to use the Scrum Framework. This isn't meant as a judgement on the team, ...


6

The first step is to get any estimation to include the whole team. Rather than just the developers estimating development effort, the estimate should consist of the effort and complexity from the entire team needed to get it finished and through testing successfully. If you couple this with not reestimating and not getting any credit until the work is done, ...


Top 50 recent answers are included