[shortlived]

The things I've taken from scrum and use at every team:

- plan in 2 week chunks

- estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev.

- make sure you define what 'done' means, and make sure it relates to what exactly you are trying to measure (Eg just coding effort, work till feature can ship?, etc). This is probably the most tricky bit.

- capture total velocity every 2 weeks and eventually use the avg for future planning

- review the entire process and modify things that take a lot of time for devs.

[bluGill]

I have long abandoned scrum for Kanban. I don't care about sprints, and getting things done by the end. Just give me (or since I'm the team leader now often I'm the one giving) the next thing to work on and when it is done I'll start the next. Nobody cares about what you got done this sprint, they care about what what got into the next release. Next release includes a lot of manual testing as despite a very great automated test program we constantly discover a lot of serious bugs in manual test that are difficult to automate.

we gave up on points. All anyone cares about is days. Thus it is better to retro on the days estimate vs days to deliver and make adjustments on our end. Nobody cares about days for an individual story anyway - they want the days for the complete feature (or at least enough of the feature that we can ship it)

[nottorp]

> despite a very great automated test program we constantly discover a lot of serious bugs in manual test that are difficult to automate

+1 :)

Yes, I could just upvote. But this deserves more emphasis than that.

[tilwidnk]

Agreed, Scrum is a death march. Kanban is the way.

[SCdF]

> - capture total velocity every 2 weeks and eventually use the avg for future planning

I have never got to this stage. Someone is added to the team. Someone leaves the team. New team members get more knowledge. Old team members get sick or take a lot of leave. The focus of what you're working on moves from one part of the code base to another.

Every time you have to throw your velocity out the window because you're not the same team any more, and those metrics are for a different team that no longer exists.

You could argue points are useful as a discussion point to make sure there isn't some massive piece of complexity hiding in something (everyone says 3 points, the quiet person who knows the most about it says 13), but even tshirt sizing covers that imo, and regardless after that you should just throw them away.

[shortlived]

Yeah, it won't work without a stable team. And that may be okay in a true agile environment but I've always had a manager who wants some type of estimate/high level schedule.

We do T-shirt sizes mapped to numbers, because recording effort in numbers lets you get an avg etc...

[ed_elliott_asc]

“Past performance is not a predictor of future success”

Capacity planning only really works where you are creating the same thing over and over.

Otherwise I’d suggest it is better to just bring work in and work on it (kanban basically)

[jsploit]

> estimate in points (relative size to something you've already done), emphasis on consistent estimates for each dev.

> capture total velocity every 2 weeks and eventually use the avg for future planning

This aspect of scrum has never made sense to me. Planning with average velocity turns points into an obfuscated time estimate - why use points at all?

[steelframe]

It's a psychological trick to counter our bias toward scheduling optimism.

[xbar]

Sounds like an agile application of scrum.