Sprint Work Items - Agile Scrum [closed]

Question

What types of tasks can be included and tracked as work items in the Sprint Backlog?

Can Analysis, Review and Unit Testing (of a user story) be included or can only core Coding tasks be included and tracked in the Sprint backlog?

Basically I am breaking down user stories into technical tasks to update the Sprint backlog and would like to know if tasks having non-coding roles can be updated and tracked in the sprint backlog.

Answer 1

You have these tasks that you want to track as work items. Be careful of doing this.

Why? You're starting to concretize a process. There's a slippery slope here. As soon as you start concretizing the process, you stop being actually Agile and start creating an inflexible waterfall of mandatory sequential steps.

If you think these things are so important that you have to write them down or the developers will forget them, then you're not giving your developers the responsibility to be agile, or the authority to make their own decisions.

You're treating them as untrustworthy.

1. Analysis of a user story. They're going to do this anyway. Why write it down? Will they forget? The point is understanding. Not documentation. Not time management.

2. Review of code. You want them to do this. You have to create the culture where this is done and the results are rewarding.

   If the results of a code review are "your code sucks, do it again", then no one participates and it doesn't get done except by fiat.

   If the results of a code review are "a new best practice for everyone to learn from" plus "perhaps you should rethink this according to other best practices", maybe people will participate.

3. Unit testing is part of a sprint without any question or discussion.
   Indeed, it is -- perhaps -- the most important part of a sprint. Unit tests come first, before almost any other code. You don't need to say this. Indeed, the act of saying it makes a claim that your developers can't be trusted to test.

When you feel the urge to write down tasks for the programmers, then you have to also think through the question why.

Why do you have to write this down? What aren't they doing?

Here's the important part.

Why aren't they doing this in the first place?

Are they not analyzing? Why not? Are you making it hard to analyze? Are the users not making themselves available?

Are they not doing code reviews? Why not? What's the road block to code reviews? Not enough time? Not enough cooperation? Not enough reward? What's stopping them?

Are they not doing unit tests? Why not? What's the road block to testing? Not enough time? Not enough flexibility? Not enough positive feedback for doing tests first?

Why do you feel the need to "control" and "coerce" your developers? Why aren't they doing this on their own?