This has the effect of having developers consider “what will I have to show for this in the next demo” when planning each story.
This is something I've been wondering about. I've seen teams increasingly working on "visual" stuff so that checkpoints are all about delivering features. Not so bad on its own, but it's made me wonder: how do you manage tech-debt in that kind of environment?
Software architect, agilist, programming language nerd, game dev by night, fitness enthusiast and proud father of two. Development Director at Unity Technologies.
You are right that this thinking could be abused. I'll make two points on this:
We trust our developers and encourage them to include technical-debt reduction and refactoring in to the stories. So if doing thing A properly requires that I start by improving the existing code base then you do it, we won't question you.
"What will I have to show" is just one way of teasing out the essence of what you are doing, it should not be the defining metric for prioritising your work.
But like with all in agile, we need to focus on honest communication between product needs and responsible development. Maybe I've been lucky but with the teams I've used it with it has worked well and people were not afraid to still pick "invisible" tasks when they considered them important.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This is something I've been wondering about. I've seen teams increasingly working on "visual" stuff so that checkpoints are all about delivering features. Not so bad on its own, but it's made me wonder: how do you manage tech-debt in that kind of environment?
You are right that this thinking could be abused. I'll make two points on this:
We trust our developers and encourage them to include technical-debt reduction and refactoring in to the stories. So if doing thing A properly requires that I start by improving the existing code base then you do it, we won't question you.
"What will I have to show" is just one way of teasing out the essence of what you are doing, it should not be the defining metric for prioritising your work.
But like with all in agile, we need to focus on honest communication between product needs and responsible development. Maybe I've been lucky but with the teams I've used it with it has worked well and people were not afraid to still pick "invisible" tasks when they considered them important.