undefined | Better HN

0 pointsvpeters259y ago0 comments

In agile, the estimates should be decided by consensus of the whole team. Requiring a single engineer to come up with an estimate is a smell.

Here is a quick 4 step planning meeting process based on planning poker:

1. Pick story from backlog, explain in a couple minutes what do you think would take to implement it.

2. Team members pick an estimate of the effort.

3. If there is consensus, note estimate on story, pick next, goto 1.

4. If there is no consensus on estimate, have highest and lowest explain why they picked their estimate, goto 2.

If you are expending more than 5 minutes on a story and there is no estimate, push it down and move on. It's not ready for development. The whole planning meeting should not take more than 1 hr.

This process, allows everybody involved in development to have an idea of the overall project and chip in with their experience to impact estimates (this might require refactoring class X, it might be hard to test, will conflict with Y and Z, etc)

0 comments

3 comments · 1 top-level

JoeAltmaier9y ago· 2 in thread

And that's where the 'incremental tasks with no architecture' part comes in. When the scheduler needs rewritten to support whatever robustness; when the server feeds need to be redundant; maybe only 1 team member has any real idea what it takes. Coding isn't always about putting up another web widget or making another database entry.

vpeters25OP9y ago

That's the point: while there might be just 1 team member with a clear understanding of the effort, everybody gets to pick an estimate based on their own knowledge of the subject matter, even if they know nothing.

The exercise of just enumerating in a couple minutes all the steps to complete such a story gives everybody, including the one who is going to do the job a clear idea of the effort or whether they need more information before proceeding.

Btw, while Scrum is great for software development, they are not ideal for maintenance and/or infrastructure management where a defined process such as waterfall might work better. Trouble tickets and bug fixes should be kept outside the sprint unless they become stories.

JoeAltmaier9y ago

Again, for a simple story where everything is known, sure. But some stories are all about figuring out how and what. The actual doing may be simple. The Scrum process fails.

j / k navigate · click thread line to collapse