Tag Info

New answers tagged

2

By-products of the sprint review include a possible change to average velocity, and feedback from the stakeholder. That feedback might end up being "no, that's not what I wanted" or "excellent! Let's use that design for the rest of the app!". All of that can potentially change the items or order of items on the backlog. Are changes during Review ...


0

I've come across this and similar problems in scrum, basically I think this comes down to whether you have a period of time where no 'work' (in terms of tasks on the board) is being done between sprints Some teams will move right into the next sprint with only a couple of short meetings Some teams will have a break of a couple of days between sprints where ...


1

As a consultant, my teams similarly have members with specializations. We need to achieve high quality as quickly as possible in order to best meet our clients needs and our organization's profit margins. It is entirely valid to have team members that are specialized for optimum performance. HOWEVER: This does not mean cross-training should not occur. We ...


0

Silos are bad for a number of reasons. Bus factor was already mentioned. When you have narrow specialization you pay the price of hand off and integration as well. I like the idea of "not doing anything" for you as a manager - that's the wise advice, however, there things you still need to pay attention to. Priority. This seems to almost always escape ...


0

First, I think that the use of the term "bug" is a bit off. There are some questions here on Programmers about this (1, 2, 3). Generally, the word "bug" refers to a defect in code. The software does not do what we expect - it crashes, it produces incorrect results, or something along those lines. I prefer to use the word "defect", and this other answer ...


1

My experience; Although there is a 'bug/defect' object in RTC (the collaboration tool used to capture user-stories in my workplace) for the most part my associates tag everything as a general 'task', regardless of whether it can be considered a bug (or group of bugs) or a non-bug task. We do have a Trac-style tool to keep track of the discovery and ...


0

Depending on the level of specialization you might consider some type of implementation of pair-programming. If somebody is under-utilized during a sprint, don't worry about velocity, and have them pair up with somebody who is being utilized in an area of expertise that they aren't familiar with. The obvious benefit of this being that members of your team ...


6

Where I work, we have a lot of silos of knowledge. Not good. The concern is that it doesn't make sense to have the GUI guy work on Networking stuff, when there is already someone that can (in terms of efficiency) get something done better because they are already familiar with it. Except of course that it leads to this sort of scenario or the ever ...


4

To some extent, there's nothing you can do if your teams are that specialized. And if you're asking from the viewpoint of a manager, there's nothing you should do, either. This is a problem for the team itself to solve. A point to remember is that scrum tries to optimize the team, not the individual. It's perfectly fine (from a scrum perspective) for an ...


4

Scrum doesn't really care about the type. A Feature, story, bug, thing, item, use-case... Anything can live on the product backlog. So it doesn't really matter what you call them. The items on the top should have a decent enough level of detail so you can forecast as far as you need and so that the scrum team knows enough to start the work and be ...


3

Who is the audience for the burndown chart? The second method, where you take credit after the completion of a story, is more in line with the ideas behind Scrum. There are several questions here on Programmers about dealing with incomplete stories (1, 2, 3, 4, and others). A story, not a task, represents something of value to the user. If you take a step ...


0

Personally i prefer the first way. It gives you a better sense of progress and the "work" done. Also many times the division into "User stories" is somewhat arbitrary. I prefer to see how much work was scheduled into the current sprint and how much was actually done. But it doesn't matter. Each team should choose what suites them best. That's one of the ...


0

I think what you are looking for is extreme programming. Most of the times if we are unable to complete the work in a given release The triangle of time / scope / cost allows you to increase one if you reduce another, not just force all three to be better, this results in the hidden fourth variable taking a hit i.e. quality. additional teams are ...


5

Is this acceptable in agile scrum? Define "acceptable". In some environments, it's fine. In most, it is prohibitively problematic. That problem is that most Business Analysts are horrrrrible. Even when they understand the product well, and even when they can define and scope features, they rarely understand much of the implications of the feature to ...



Top 50 recent answers are included