Hot answers tagged

8

It reassures your stakeholders that the bug was, in fact, fixed. It might help them understand what was wrong in the first place, and therefore why it was prioritized. In some cases it could prompt a broader conversation about desired behavior, edge cases, possible new functionality, etc. Remember, the goal of the demo/review is to use the recently ...


6

Welcome Ayesh! You have 3 options, and the best option to choose will depend on the details of what is going on: Ignore the critical bugs for now. Finish the sprint you're doing now, and put the bugs at the top of the backlog to be worked in the next sprint. This can be a good option when the sprint is going to be complete in a few days anyway, or when ...


3

Bottomline: go for the approach that'll help you solve the end user needs (features or bugfixes) faster. A task should reflect the issue from end users view. You can do a triage, but I'd avoid rephrasing what the user has complained about. There are three main reasons to stick to user wording: it's a waste of time to rewrite what's already written ...


3

First of all, every customer facing bug has an impact on revenue. That impact can be big or it can be small, but the impact is there. With that in mind, I would recommend extending the criteria for the various urgency levels to include guidance on the possible revenue impact. For example, bugs with a low revenue impact can fit in the lowest urgency class, ...


3

I am finding it hard to see what value could it bring to have that many people reviewing this on a meeting. Perhaps you can ask your stakeholders to check bugs offline? Other two good questions for them are: How much time is being invested in this? How many times have they found "issues" in the bugs? <-- be aware that if this happens often, then you ...


3

The Scrum Guide is a good place to turn. The Sprint Review (timeboxed to 4 hours for monthly Sprints) is split into two parts. The first part is for inspection contains a demo, and its essence is: During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. This is to enable the second phase, in which: ...


2

When you receive a bug report, it needs to be triaged. The workflows that I use tend to look something like this: Review the bug report and confirm that it truly is a bug. Some people who report issues may not be aware of the intended behaviors of the system. The issue reported could be acting as designed. Assuming that the issue is a bug, check the quality ...


2

TL;DR Should we extend the Sprint, or finish the Sprint on the delivery date and move the remaining tasks to another Sprint? Scrum is a time boxed framework that values a predictable cadence of events. Work that can't fit into the current time box must removed from the current time box, or the entire time box scrapped so the Scrum Team can adapt to newly-...


2

Your proposal has one thing that I found interesting: Team member try to reproduce the bug and details how to reproduce it. Does this mean that currently no information is stored on how to reproduce a bug? If you don't, start doing that! The team can define a minimal amount of information needed to be able to discuss it. Think of things like: A clear ...


2

I could provide feedback on your current way of working and your proposed change, but it is better if the team are the ones making decisions rather than outsiders. As a Scrum Team member you have made a suggestion to adapt your team's way of working. Next steps would typically be: Bring your suggestion to the team retrospective, or ask the Scrum Master to ...


2

TL;DR: A bug should always go to Product Backlog. If you cannot afford it, get ready for unplanned work and bring it during next retro to agree a new workflow. Both flows presented are both creating unplanned work during the actual Sprint. That's because you're dedicating time (either on meetings or on detailed analysis) on something that was not planned. ...


2

TL;DR We have been asked to demo almost all bugs in our sprint demo, except the bugs which were raised for the stories of the sprint...Is there any benefit in demoing bugs? The benefit, if any, comes from whether or not the bugs were part of the increment of work planned by the team. If fixing certain bugs was a goal for the current Sprint, then covering ...


2

There are several ways of tackling this, I've tried most of them and none are ideal simply because you are dealing with what Scrum calls "unplanned work". One of the most important things, in my experience, is having a good bug triage system in place. When a bug is reported, someone should make an informed decision, based on a company-wide-known policy, ...


2

we use something which resembles scrum My suggestion to you would be to move closer to Scrum by looking to have a potentially shippable increment at the end of each sprint. Note that the key word for you here is 'potentially'. You can still release every six months if that is what your Product Owner wants to do, but you should still target having something ...


1

The main problem I see is that you are releasing each 6 months, which is too rare. There's a reason why Scrum says a maximum of 4 weeks per Sprint. Because at the end of the 4 weeks, the increment needs to be potentially releasable. You don't have to do it, but it has to be in this state. So, because the releasing cycle is too long, your customers raise ...


1

While you are resolving the problem of how to allocate time for bugs, you may also want to look at ways of reducing the number of bugs you're finding. You may be able to catch them earlier in the process, leading to less rework later on. There are a number of methods/tools to help do this - peer programming; code reviews; static code analysis tools; ...


1

There are a couple factors to consider: 1) What is the timebox of your sprint review? Scrum lays the framework, but it's up to you to maximize the value and efficiency of your team within that framework, especially during scrum ceremonies. If your team expresses desire to shorten scrums, you need to focus on what provides the most value in the time that ...


1

There are several ways that you can deal with bugs. But regardless of your bug policy, there is one thing that you really should do. If your developers are spending a significant amount of their time on fixing bugs, you should give it a high priority to find out where those bugs are coming from and what can be done (on a technical level or on a process ...


1

The short answer is: Bugs are drag, don't assign points to them. The long answer is: The key idea behind story points is that they represent business value. The question is, how much business value can you provide each iteration, a value that is used to interpolate into the future. All things that don't provide any direct businesses value, writing TPS ...


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