The Stack Overflow podcast is back! Listen to an interview with our new CEO.

Hot answers tagged

42

I cannot speak to your particular situation but yes, it is pretty common that not everything is done. This is in fact a logical consequence of the structure of the team, and you being a developer are in a prime position to appreciate it. Load and delay If I were to ask you “do you run a server at 100% load?” you would likely laugh in my face. So I might ...


27

I'm going to slightly disagree with Bogdan's answer. The Scrum Guide does say that: Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. We normally think in weeks, so I translate "one-month Sprint" to "four-week Sprint". However, it goes on to say that if the Sprint is ...


22

From the Scrum Guide: Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. All of the events are included in your Sprint timebox.


19

Working sprints that end/start mid week is usually more effective/efficient than ending on a friday and starting on a monday for several reasons: It makes the last minute rush to complete work more painful and less desirable for the development team (eliminates the excuse of, "hey we can finish it over the weekend). Reduces the risk of paying weekend ...


19

In addition to the questions that Daniel poses, I'd pose a different one first: Is the team achieving its Sprint Goals? The Sprint Goal for a team following Scrum is the objective that should be met at some point during the Sprint by implementing Product Backlog Items selected for the Sprint. It can help focus the team's efforts toward specific work and ...


18

In my team, if the backlog was exhausted, we always had the following to fall back on: The team can invest time and create a prioritized backlog of technical / architectural debt in your systems Work on technical debt items created using point 1 (above). Improve the automated continuous integration and continuous process. In the world of infrastructure as ...


17

The idea behind the fixed length sprint is to provide a understanding between development and the customer (or PO) when something new (and working) will be available, and to define the length of the feedback loop, which is equals to the length of the sprint. In other words, the customer will know that she will get something in 2 weeks, which works, and the ...


16

TL;DR I was wondering if it's a good idea to name Sprints with user-friendly names instead of using numerals like Sprint 1, Sprint 2, etc. No, it's not a good idea. A sprint is a container where Product Backlog items are temporarily stored for a brief duration. A sprint may produce some project artifacts, but the sprint itself has value only as a time-...


16

Jeff Sutherland, the inventor of Scrum, developed a pattern called 'Illegitimus Non Interruptus': Explicitly allot time for interrupts and do not allow more work than fits within the allotment. If work exceeds the allotment, abort the Sprint. - Scrum Patterns Group You will likely have historical data on how much time you should allot. Look at frequency ...


15

Name the Sprint after the Sprint Goal If you want to name a Sprint, I agree with the accepted answer in the programmers.stackexchange.com thread that you should name it after the Sprint Goal. As the Scrum Master, I keep pushing the Product Owners to come up with a well articulated Sprint Goal. I always start my Sprint Planning sessions by inviting the ...


14

TL;DR Missed estimates are not an opportunity for blame, but rather an opportunity to inspect your process and adapt it to fit the requirements of your organization. The Product Owner, the Scrum Master, and the Development Team must all work together to learn from the failed sprints. Misconceptions It seems like the entire Scrum Team is working under some ...


14

If you are following Scrum as defined in the Scrum Guide, the Product Owner cannot simply add stories to the Sprint Backlog. The Sprint Backlog, which is created as Sprint Planning as a negotiation between the Product Owner and Development Team while considering past performance and forecast capacity, is owned exclusively by the Development Team. If work ...


13

The Sprint backlog is a forecast, not a commitment In the 2011 revision of the Scrum Guide Jeff Sutherland and Ken Schwaber made an important change. They changed the word "commitment" to "forecast" in regard to the Sprint backlog. The term commitment has two bad consequences: The stakeholders expect to have every single item delivered at the end of the ...


13

So this is something I'm dealing with right now in AOL. The constant desire of business to measure seeps even into agile organizations. The key is to make sure you are measuring in a way that does not damage the fabric of agile for the sake of measuring. We must always be very careful and mindful of Goodhart's Law: "When a measure becomes a target, it ...


13

It is common, but it isn't right. Here are a few things to consider that may be contributing to this challenge: Is the team focused on delivering a potentially shippable product increment each sprint or just doing work in a larger project? I hear a lot "it doesn't matter, it all has to be done on the deadline". If I hear that, they're probably right. They ...


12

Basically, a burnup chart is simply a graph plotting both the total story points across the project, and the amount of done story points (both on ordinates), over all iterations (on abscissa). See for example this comparison with burndown charts. So, in order to build a burnup chart, you simply have to do the following for each iteration: sum story points ...


12

TL;DR Scrum doesn't enforce batch sizes on stories the way some other methodologies do, so individual story sizes can vary dramatically. The important thing is that the aggregate of all stories should fit within the defined Sprint length, and the team is expected to adjust its processes as needed to optimize both estimation and Sprint Goal completion. In ...


12

There are different conventions I've seen used. In my opinion, even having one is completely irrelevant, besides giving you something to refer to in discussions (which may or may not be a good thing!) Use a «Sprint N» or «Iteration N» convention: Pro: Easily generated Con: Is anyone going to remember what you did in iteration 23? It's almost like not naming ...


12

From the Scrum Guide: During the Sprint: No changes are made that would endanger the Sprint Goal; Quality goals do not decrease; and, Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. The changes you mention fall into the last category, unless they endanger reaching the sprint ...


12

Perhaps a more accurate way to put it would be that story point estimates are imprecise. If you have a 5 and a 3, that may or may not be the same size as an 8. To make this less confusing, let's start with a non-numeric scale like T-Shirt sizes. XS, S, M, L, XL and so on. We can agree pretty easily that a small and a medium t-shirt do not get you a large t-...


11

No guarantees on this one, but here is what I would try: Either they are not understanding your documents or they are not doing the work and using the documents as a scapegoat. It is a little extreme but ask for a restatement of your documents along with their anticipated approach. Get this by the next day as a precursor to them commencing work on the ...


10

I totally agree with Michael and Mark. Both nailed the problem with the ask for a restatement of your documents along with their anticipated approach. They're clearly not understanding the requirements. The problem is... are they trying to understand beforehand? If they're not analysing the requirements and jumping straight to the dev, they'll have a hard ...


10

I gave Sergey's answer a vote, solid ideas. I think Sergey's answer works well at smaller scale, in an Enterprise class program or multi-scrum team program you might have a little more success if you bring in Release Planning as a formal activity and do the majority of your work in the Backlog Refinement (Story Time) meeting. Here's why- So it would go, ...


10

Briefly: No, Daily Scrum with Three Questions is not a sign of team immaturity. Yes, Daily Scrum with Three Questions is valuable, even if you with your team want to switch to Extreme Programming. Verbosely: No, Daily Scrum with Three Questions is not a sign of team immaturity. In reality, I don't understand, why Daily Scrum with Three Questions should ...


10

I have seen almost any day but Monday and Friday, because people want to leave early on Friday (assuming you have flex time) and might come in unpredictably late on Monday if they are contractors that went home over the weekend and only arrive in your city on Monday morning. Those days are also prime targets for single days off to have a long weekend and in ...


10

In Scrum we look to create product increments each Sprint, not simply to do work. The direct solution to your question from the Scrum Guide is that you should have cross-functional team. That is, all skills needed to deliver a full product increment should be on the team. There are circumstances where this may not be possible and you are stuck in the ...


9

In a truly agile environment, does the PO go to the level of saying things like, "OK, we have 40 person hours of work for Arthur and 32 person hours of work for Candace, and since they're each supposed to be half-time on this project, they should finish that work by the end of the next sprint." ?? Well, in a Scrum environment, or in any other ...


9

TL; DR It really sounds like the Scrum Master and the Product Owner have both bought into the velocity and utilization trap. Break the cycle. Dissecting the Product Owner Role The PO wants to know how many hours programmer X has available during each sprint and exactly what he will do with them. Not his business in a Scrum shop. He is part of the Scrum ...


9

TL; DR You actually have two questions. One is about time-boxing, and the other is about estimation. Time-boxing and estimation are the very essence of Scrum. If you aren't adapting those two practices for your team, whatever you're doing isn't really Scrum. Tools and Practices Aren't Silver Bullets [Incremental development] just doesn't seem to bring ...


9

One of the primary reasons for the fixed sprint length in Scrum is to make obvious various problems your team(s) might be encountering. Removing the regular cadence will make it more difficult to see these problems and address them. For example: if you consistently have trouble completing functionality within a timebox, that may be a sign that you are not ...


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