Hot answers tagged

14

In the context of Scrum, a Sprint is a timebox. It has a start and it has an end. Once a Sprint starts, it's timebox is fixed - it will end when it is scheduled to end. There is no concept of adjusting the end date of the Sprint because things come up. Based on this and the problems that you're describing, I do have some suggestions. First, I would ...


7

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


6

Jeff Sutherland, one of the creators of Scrum, provides an answer in his book Scrum: The Art of Doing Twice the Work in Half the Time: And so my team embarked on what we called "Sprints". We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and then stop to see where we were. In ...


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


6

The Scrum Guide says about a Sprint that it's "a time-box of one month or less". So based on that, the sprint duration can be whatever you want it to be in that duration interval, but people usually chose weeks as their Sprint duration: one week, two weeks, three weeks, one month. And yes, that includes weekends. When people say 30 days Sprints, they ...


6

Retrospective actions are a vital part of the Sprint work, so they should be agreed with PO and tracked as such. You mentioned you use a Kanban board. Why not tracking each action as an item in the board? You may want to have a mean to separate these items from the other Stories, but it all boils down to what works better for you. In our team, we use a ...


5

It's important to realize that, in Scrum, there is no such thing as "Iteration 0" or "Sprint 0". All Sprints are the same and all result in a potentially releasable Increment. However, Scrum isn't a complete product development life cycle. There are several early-life cycle activities that fall beyond the scope of Scrum as it's defined in the Scrum Guide. ...


5

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


4

1 Lower capacity on that sprint for the members that constantly get pulled off, to accommodate the "flux" of other demands that crop up? Yes. But report this clearly so the impact is understood. The potential for this exists on every team. Among other things, people get sick. Scrum can't control this but it can show the impact and how the team adjusted ...


4

Where do the competing priorities come from? Can you track them on a common backlog in "Scrum of Scrums" fashion and find a common Product Owner who could help set consistent priorities? Scrum emphasises fixed time-boxed iterations. The idea is to fix the length of a sprint and then stick with it so that the team and stakeholders can have some confidence in ...


4

A common theme in agile methods is about communication, visibility, and transparency in the work that is being done and what the status of that work is, ensuring that the right stakeholders have access to this information. Without knowing all of the details about this work, it seems like the Product Backlog is not the right place for these. The Scrum Guide ...


4

There is a single sprint goal, to prioritize the sprint backlog. The team goes about what the do and when, but they need guidance. The goal is not from the user's perspective, the goal is about what the PO wants to achieve with this sprint. That might be something from the user perspective. It might not. Having sprint goals in advance is counterproductive. ...


3

Every Sprint must produce a product increment, right? Working software. But when you start any project, you don't ever hit the ground running because you might need to prepare things: setting up the project and access rights, infrastructure work, buying and setting up servers, adding enough meat to user stories to actually be able to work on them, etc. ...


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


3

Introduction: Focus on Right-Sizing Your WIP A lot depends on your framework. As you simply tagged your question agile, it’s almost impossible to give you a universal answer. Nevertheless, controlling work-in-progress (WIP) will likely be key. Kanban In Kanban, you would typically reduce your WIP for other work states (e.g. development) in order to ...


3

How to deal with recurring tasks in a sprint? It really depends on what type of work is performed in those recurring tasks. If the work is about fixing bugs for the application, adding new functionality, any kind of product enhancements, or work that creates a product increment and can be a goal for sprints, then it belongs in your sprint and in your ...


3

Like most things, it depends. In theory, you could forecast when work is likely to be done. If you understand your team's average velocity (whether it's in story points per Sprint, ideal hours per Sprint, backlog items per Sprint), you can forecast when you will get to a particular item on the backlog. However, there are a lot of caveats with this. It ...


3

TL;DR A Sprint Retrospective is part of the inspect-and-adapt process. The 2020 Scrum Guide says that "[t]he most impactful improvements are addressed as soon as possible," but doesn't prescribe how the team must implement any given adaptation. The whole Scrum Team is collectively responsible for working together to decide how to best implement ...


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


2

From what you write it would seem Scrum is not a good match for your team's work. Yes, you could cut down the sprint's capacity of your team, to accommodate the unforeseen tasks that crop up. But that would only be helpful if the amount of distraction is somewhat constant across sprints (which is probably not the case). Repeatedly shifting the sprint end is ...


2

The Sprint Goal is a focusing tool for the Development Team. It is not necessary for all work selected for a Sprint to be aligned with the Sprint Goal. In fact, I usually recommend that the Sprint Goal should be something that can be met through the completion of at most about 60-70% of the Product Backlog Items selected for the Sprint. If the Development ...


2

One thing I wish to add to the accepted answer, is that you shouldn't take the meaning of the word "Sprint" literally. You see from Thomas Owens' answer that it was a name attached to the way they structured they're work. In a sprint in a sporting event, participants prepare for the sprint (e.g. warm-up), start the sprint when the signal is given, cover a ...


2

Iteration 0 is a bit of a misnomer. There is no such thing in Scrum and it is often abused. So let me first start with the bad, then how I've seen it used well. The Bad The problem is that in Scrum, the product is meant to be developed in increments with the result of each sprint being potentially releasable. Where this falls apart with an iteration 0 is ...


2

Iteration 0 is not a formal part of Scrum, but the best definition I have heard is: Form the team and have sufficient work in your backlog for at least one sprint


2

TL;DR This is a good question because it exposes a common misunderstanding about Scrum theory and the value of a Sprint Goal. To illustrate your use case, though, you'd need to craft a Product Backlog from which the Scrum Team can extract backlog items that fit a central coherence. A Product Backlog that doesn't lend itself to unified Development Team ...


2

New requirements come up all the time and go on the backlog for future sprints but I expect you mean the PO wants to add it to the current sprint. The PO should have the final say about the goal of the sprint. Given that you are half way through I would expect a conversation between the PO and the development team to work out what the impact will be. Maybe ...


2

In Scrum, the Product Owner has limited power to improve quality. I see 2 potential actions: Manage the Product Backlog accordingly. If the timeline is too tight, try to find items which can be potentially removed or replaced by a simpler but sufficient solution. Write more accurate user stories and acceptance criteria. While the tumb-rule suggests not to ...


2

The tool you want is a burnup chart. JIRA has them built in as Release Burnup Chart or Release Forecast Chart (they keep changing the name), but the feature in JIRA is limited that it only forecasts the whole release. However, you can build these charts by hand - they may seem difficult at first, but they're very fast and very easy once you get the hang of ...


2

Two cases come to my mind Is everyone ok with you sharing the information? Does it make sense to share all information? Once you clarify that everyone is ok with sharing that information and you decide that it's a valuable information to share, great. My suggestion in how to share them would be based in a bullet from this answer Do a retrospectives on how ...


1

Even if you are not doing Scrum, there is nothing special about an iteration 0... In any Agile methodology, you deliver something of business value with each iteration - no matter how primitive. This actually highlights both the benefits and weaknesses of Agile because it prioritizes delivery over planning - potentially at the expense of overall ...


Only top voted, non community-wiki answers of a minimum length are eligible