What tasks that 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 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.
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.
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.
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.
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?
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).
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.
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!
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.