New answers tagged

0

A common solution to this problem is to have a separate shorter story called a design spike. This is where one team member explores possible designs, perhaps trying a few manual proofs of concept, then documents the results and reports to the rest of the team. You allocate some time for this in the previous iteration. The output of a design spike is ...


1

If I may, I'll turn this question on its head: how far into a task do you realise the estimate was wrong? Let's take an example: I estimate a story will take me three days. Two days into it, I realise it's likely to take six days. So ask yourself, if it took me 16 hours to work out it's a six day task, how long would it take the team to work this out when ...


3

In general, you should have already looked at the stories and had an idea of an estimate or what obstacles might exist and need to be discussed prior to the planning meeting. This process is part of backlog grooming. This may or may not involve having a meeting about it. You should also be estimating beyond the current sprint, but you can revisit ...


0

You get into trouble when you try to be too literal or adamant about anything in software development as much as we all really want things to be cut and dry. Bugs should get fixed before new features are added, but I would still consider the importance of each when making this decision along with the scope of the problem. There are exceptions to everything. ...


0

Is my understanding of average velocity and sprint commitments correct? Unfortunately, you've been misinformed about a few things regarding Sprint Planning in Scrum. First, the Development Team (DT) is ...structured and empowered by the organization to organize and manage their own work. - Scrum Guide The word for this is self-organizing. This ...



Top 50 recent answers are included