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.

Kylix

might I suggest: area51.stackexchange.com/proposals/9543/… – Blithe

+1 in sympathy of the pounding you're going to take from members for wording your question this way, especially the last paragraph :) – Grannias

@Blithe You might suggest but there is nothing wrong with asking this question on SO. – Thymelaeaceous

This question is off-topic because it is not within the scope of questions appropriate for this site, as defined in What topics can I ask about here? Please also see: What types of questions should I avoid asking? You may be able to get help on another Stack Exchange site. – Comeau

I'm voting to close this question as off-topic because it is not about programming. – Devilry

Answer 1

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

As per Scrum Guide ->In the planning meeting part 2, the Team identifies tasks. These tasks are the detailed pieces of work needed to convert the Product Backlog into working software. Tasks should have decomposed so they can be done in less than one day. This task list is called the Sprint Backlog. So whatever task which meets the above guideline needs to be included.

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?

Yes, they can and should be included if doing them leads to converting the Backlog to Working Software. Scrum NEVER suggests to include only coding tasks in a Sprint Backlog. In fact Scrum asks the team to be cross functional.

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

This sounds suspicious to me. Is it just 'You' who breaks down tasks? It should be the whole Team breaking down tasks in the second part of the planning meeting. Again non coding tasks can be included in a Sprint. Just to give you a realistic example: In my Web Development Team a typical Backlog had the following tasks. 1. Define and Discover 2. Design and Create Test Matrix 3. Write Unit Tests to Test Matrix 3. Code to make Unit Tests pass 4. Test 5. Regression Test 6. Debug 7. Go over 'Working Software with PO (if required to make sure this is what PO wants)

EDIT

One more point about tasking. The tasks added during planning should constantly be broken down/updated/renamed when necessary. The whole point of this is to add a transparent set of decomposed pieces of things to do, which when done completely, eventually leads to working software following QA standards, most efficiently and effectively. These tasks should be picked up and worked on cross functionally and should not be blocked amongst team members.

Hope this helps!

Grannias

Answer 2

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?

Knew

Thanks for your response. what I mean is requirement analysis, code review and unit testing the code. Yes, they're not deliverables in the Agile sense but are essential to ensure code quality in my view and we will have to spend effort for that. – Kylix

@jcs: Please update your question to make this perfectly clear. – Knew

+1 I love how you phrase everything as a question, great retrospective material – Shoifet

Answer 3

The short answer is - whatever works best for your team and the user story in question.

For example, if we're working on refactoring a piece of code as part of a user story, we may break out a separate task to handle putting it under test first. But if it's new dev, we infer that it will be under test (and usually done with TDD) as part of our process.

Other examples include sometimes breaking out a separate task to cover time spent for coordination vs. coding, integration testing with external vendors, etc. - basically, any discreet and measurable task that helps make up that specific story (including some of the examples you have included above).

Bottom line is that there is not a set formula for what every story should have, rather tailor the tasks based on the individual needs of each story (even of those tasks are not code related).

Podgy

Thanks. Appreciate your response. – Kylix

Answer 4

If you create task for Analysis, Coding, Review, Testing, etc. in each user story you will get close to something called Scrumfall (each iteration divided to waterfall stages). It is one of the Scrum smells. Basically such activities should be included in single task: "Do something" means do everything you need to complete "something" = you are professional developer and you know (or it is said by policy) what has to be done to complete task.

That is general case. Sometimes you indeed need to divide tasks to "activities" but first you should start with common process and use this tool only if you have real reason - for example spike task in one iteration and real task in second iteration.

Edit: I used dividing tasks into activities once. We didn't do TDD but tests were written after completing the task. So each development task was paired with testing task to show that it could be done by another developer and sometimes in parallel with development. But the responsibility of testing by another developer was team decision and for complex tasks they really did that.

Liliuokalani

I agree only to the point where you imply a template form of tasks should not be followed for each Backlog. But at times a Backlog may actually need Analysis, Coding, Testing and there is nothing waterfalish about it. My justification? In waterfall - the whole organisation structure is different - the analysis team, the coding team, the qa team, all are silhoed. In scrum the team is crossfunctional, and ideally everyone is involved in every stage right from inception to end of the backlog. – Grannias

It can be called a Scrum smell ONLY if the tasks are blocked within the team from other team members and not kept transparent involving everyone. I can give real examples of how the implementation is way different than waterfall. And it certainly cannot be called Scrumfall or mini waterfall. – Grannias

@sjt: I didn't write that he is doing Scrumfall, I wrote that he is getting close. But very good point because question does not mention if each task can be done by any member or specific member. My answer is simply about one of the main agile tenets = Empower people. Create high level task and give the responsibility of choosing activites to the guy who will do the task. – Liliuokalani

Answer 5

If you focus all the effort you are applying to task tracking to splitting your stories smaller (1-3 points) then you will working on becoming more agile. Small stories have almost no need for task level estimates or tracking. Your PO gets the benefit of being able to prioritize smaller sets of features and you get to focus on delivering value instead of documenting obvious steps repetitively. Certainly tracking a team's agreed upon standard practices by the hour per story is not at all useful.

Shoifet