I’d add one thing to that list:
Control the amount of Work In Progress by the team.
I’m not sure if that counts as common sense or not but I see it as vitally important.
Control the amount of Work In Progress by the team.
I’m not sure if that counts as common sense or not but I see it as vitally important.
Having worked as a programmer since 1999, I can say that these things were not part of the processes and ideas when I started, at the places I worked. Interpret that any way you want.
I like agile/ scrum/ whatever and what I mean when I invoke those terms, is the list enumerated above.
I dislike the bullshit derivative terms, however. The burn-down charts, estimation poker, story points and all that. (Sure - the poker might trigger a thorough discussion about controversial estimations, so I guess I'll allow it.)
I also really dislike the concept of the daily standup for non-juniors.
I believe all these tools have their place. But they are more frequently used by management to exert power over engineers. “What a dumb take. That feature obviously will not take that long. You are over-cautious as always.” “We had decided that this feature was 2 story points. Why did it take that long?” No, dumb fuck. It was your decision, not mine. I had argued against it, but you didn't listen.
(I'm suggesting that the problem in your process might lie elsewhere - with mapping points to time, maybe, because the points system should be self-correcting to that kind of gaming).
That’s common sense, otherwise we’re just not taking real-world problems into consideration.