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.
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!