Tag Info

New answers tagged

5

Don't do this. You're not going to like this, but you're missing the point of story card sizing. It's NOT to measure productivity. It's to measure relative complexity of work. These are not the same thing, and never will be. See, there's a fuzzy correlation between requirement complexity and time to completion, but that's ALL that it is. Your goal ...


1

I'm not sure this is the right forum for this question, but since similar questions are already here, my advice (out of experience) is: Don't bother explaining. Rather, show him. In particular, if you want to introduce agile or scrum processes, you'll have to do two jobs: on one side, report him the data he wants (Gantt charts, estimates). On the other, ...


1

Whatever the methodology, a product will fail if participants aren't motivated. As a Scrum Master, you're part of the team, not above. The good news is, that makes at least one motivated team member :) You must ask "why are we failing ?", not "they". The best time to do that is during a retrospective. Bring up the point that the team's velocity hasn't ...


1

@JeffO There is one more which I want to go into detail about: Thesis 1 These two programmers estimate right but have incomplete knowledge (So do I). This is a two-programmers-team and those two programmers are very disconnected from the other teams. base their work on a lot of foreign work which is hard to estimate Since they are only two people it ...


1

I would question every team that gets ever sprint completed all the time. This really isn't the goal. It's all right to push yourself even if it means missing a few. You can always adjust. If they can accomplish everything on time towards the end of the project, maybe they figured it out. Developers are going to underestimate because: There are serious ...


2

The sin of overestimation is probably less serious than that of underestimation, because the team is at least meeting its commitments and not contributing to the chaos that can occur when commitments are missed (particularly when others depend on a team's output for their own work, as is often the case). How do you know they are overestimating / ...


0

The idea of having a "bucket" backlog is something my organization started with but moved away from. We resolved this problem by moving to Area Paths by module. For example, we have a Web Services, Web Interface, and Data Access area path for one of our team projects. You could also consider using TFS 2013's Initiative and Feature work items, but as far ...


1

However in Scrum you are only supposed to have user stories that provide value to the user. In our case the UX design stories don't provide such value (they are more like a backlog grooming activity). The way I see it, they are providing lots of value to their user. The thing is: their user is not the company's final user, their user is the ...


3

There are two issues here, one about user centered design and the other about sprint alignment. First: User stories should be aligned with user needs, not just backlog. The UX stories need to have clear value to users. This does not require complete specification, and a short statement such as, "Users will have easier access to account activity on a ...


0

The last I heard was that it was 1.5/2x the number of team members. Also note, that Mike Cohn is not implying you should use these numbers, he is simply saying that over the many years in the industry and the many teams he has coached, he has found 1.5x/2x stories per team member to work best. He gave this answer when I asked him what he considered to be ...



Top 50 recent answers are included