Agile Test Management using TFS, VS & MTM

                       

Speaking about Agile planning & management with Agile tools like TFS, VS & MTM leads us specifically to Scrum, where in we concentrate on the below items

First of all lets see the hierarchy of Work Items followed in Scrum process.

Workflow states Agile process comparison:

Workflow states define how a work item progresses upon its creation to closure. For example, the four main states defined for the User Story (Agile process) define a progression of four states, from New, Active, Resolved, to Closed. (The Removed state supports removing a work item from appearing on the backlog; to learn more, see Move, change, or delete work items.)

The natural progressions and regressions of the user story, product backlog item, and requirement WITs are as shown.

Roles in Agile Scrum

Under Work Tab we can see backlog, board & work Items. we will discuss whats the importance of individuals

Product Backlog:

So what basically is a product backlog?

Backlog is just an ordered list of idea's, where we can order them based on priority.

An interactive list of work items that corresponds to a team's project plan or roadmap for what the team plans to deliver. The product backlog supports prioritizing work, forecasting work by sprints, and quickly linking work to portfolio backlog items. You can define your backlog items and then manage their status using the Kanban board.

Product backlog item

A type of work item that defines the applications, requirements, and elements that teams plan to create. Product owners typically define and stack rank product backlog items which are defined defined with the Scrum process. 

backlog contains 2 sub sections

1.contents

2.capacity

Contents contain ordered list of idea's, where we can order them based on priority.

As shown below is a list of idea's with their status, efforts or story points & Iteration path

Basically story points are the measure  of the size of User story, usually an estimation of efforts required for the User Story - which is not days/hours, etc

Story Points:

A story point is an abstract measure of effort required to implement a user story. In simple terms, it is a number that tells the team about the difficulty level of the story. Difficulty could be related to complexities, risks, and efforts involved.

mostly calculated using Fibonacci sequence: 1,2,3,5,8,13,21

Sizing is done ideally by the Agile delivery team (normally scrum team)

Story points along with sprint velocity provide a guideline about the stories to be completed in the coming sprints.

How was the sizing process done?

Outlined below is the relative sizing process:

1. List all the stories to be sized

2. Put them in order from smallest to largest

•  Take the first user story
•  Then take the second user story
•  Decide which is bigger and put the bigger one above
•  Then take the next one and decide where it fits relatively to the other two
•  Then take the next one and do the same
•  Repeat the process until all the stories are now in the list (in a sequence from smallest to largest)

3. Size the stories

• Start from the bottom and give that story a number 2 story points. Giving ‘2’ provides you the room to give a smaller story ‘1’ if discovered at a later stage.
• Look at the next story and decide how big is that story as compared to the first one
• Continue until you have a size on each story
• Use these set of numbers [influenced by Fibonacci] while sizing:1, 2, 3, 5, 8, 13, 21

Recommended not to emphasize on the story points during sprint planning and focus more on estimating the time needed to complete all the tasks involved in the user story.

Below pictorial representation clearly specifies which needs to be done at what point in time.

Area path & Iteration path:

A node on the Common Structure Services hierarchy that represents a feature area. Area paths allow you to group work items by team, product, or feature area. Whereas, iteration paths allow you to group work into sprints, milestones, or other event-specific or time-related period. 

Sprint planning

During the planning meeting, product owner works with the team to identify those stories or backlog items to be completed in the sprint.

Planning meetings typically consist of two parts. In the first part, the team and product owner identify the backlog items that the team feels it can commit to completing in the sprint, based on experience with previous sprints. These items get added to the sprint backlog. In the second part, your team determines how it will develop and test each item. They then define and estimate the tasks required to complete each item. Finally, your team commits to implementing some or all of the items based on these estimates.

We go head with the following as a part of Sprint planning process:

1. Assign backlog items to a sprint
2. Set your team's capacity
3. Add tasks to backlog items
4. Adjust work to fit team capacity
5. Share your sprint plan

1. Before you start planning your sprint, you'll want to have created, prioritized, and estimated your backlog.
2. Also, you'll want to have set the start and end dates for your sprint.
3. Begin your planning efforts by moving items from your backlog to your current sprint, one item at a time. Simply drag each item from the product backlog onto the sprint.

Sprint backlog

An interactive list of work items that have been assigned to the same sprint or iteration path for a team. The sprint backlog supports teams that use Scrum methodologies.

Task board

An interactive board of work items that support reviewing and updating tasks defined for the sprint backlog. The task board supports teams that use Scrum methodologies.

User story

A type of work item that defines the applications, requirements, and elements that teams plan to create. Product owners typically define and stack rank user stories. User story is defined with the Agile process.

User Stories are further broken down into tasks- say Dev task, QA task, etc. wherein these tasks get the actual estimates.

Velocity Chart:

Velocity is the number of story points completed by a team in an iteration, can be visualized from Work=>backlog, clicking the bars on the top right allow us to visualize the velocity in each sprint.

Team velocity is the rate at which a team delivers stories from the product backlog. If you know your velocity, you'll have an idea about:

• How much value you've delivered until now (in story points and done user stories), and
• When you'll be able to deliver all user stories in the product backlog, and
• How many story points will you be able to deliver by a certain date.

How do we calculate velocity?

Assume Our team delivers 3 user stories. The sum of the story points equals 20. Our velocity is then 20.

If, in the next iteration, our team delivers 30 story points, then our average velocity is 25, or (20 SP + 30 SP) divided by 2 iterations = 25 SP.

If your team has completed multiple sprints, you can forecast release and product completion dates and plan future projects more accurately by reviewing the velocity report. Based on the velocity of previous sprints that the report illustrates, you can accomplish the following goals:

• Track how much effort your team has reported as complete for each sprint.
• Estimate how much backlog effort your team can handle in future sprints if your team composition and sprint duration stay constant.

Why do we need it?

We need velocity to:

• Predict how much scope can be delivered by a specific date
• Predict a date for a fixed amount of scope to be delivered
• Understand our limits while defining the amount of scope we will commit for a sprint

Each sprint that has been assigned to the team project or to the team appears along the horizontal axis. The vertical axis indicates the sum of all effort for all backlog items assigned to the indicated sprint that have been closed (State=Done). 

How to Edit the Iteration/Sprint Dates?

Backlog Priority (Scrum) or Stack Rank (Agile and CMMI)

You can assign a value to the Backlog Priority (Scrum) or Stack Rank (Agile and CMMI) fields, you'll be assigning the same value to all items you've selected for bulk edit. These fields are used by the system to track the relative ranking of items on the product, feature, or epic backlogs.

To the right of the screen, we can see the division of the Sprints total estimated hours which is 135 hrs. But the capacity we have is only 50 hrs. so where do we fit the rest of hours from?

Capacity:

It 's the place where we setup the teams capacity say the individual per days work hours, no of days off within the sprint

Capacity is calculated from Work=>backlog=>Sprint=>Capacity, add the members of the team & provide per day capacity, activity done by the member[Testing/Development], Days off within the sprint period.

In the above screen shot for example, Capacity is calculated as 50hrs, which is based on

Capacity => (No of days left in the current sprint)*(Total per day capacity of all the team members)

From this [work - in the right side], we can actually see the committed time lines for a User story & the progress of the remaining hours left out & can further be drilled down to Testing & Dev Tasks based calculation & also further down to individual resource hours remaining.

Board

It gives us the visual representation of Stories on the left & the corresponding task assigned to them on the right.

We can drag & move the tasks from To Do to In Progress & to Done.

We can view the stories & tasks drill down by person from top right filter Person.

We can view the Burn Down Chart from the top right blue box, which is shown as below

User Story Grooming:

Discuss & Clarify any open questions with regards to the User Story.

Acceptance criteria

Acceptance criteria define what "Done" means by describing the conditions that the team should use to verify whether a requirement or bug fix has been fully implemented. You can capture these criteria in the work item. Clear acceptance criteria help with estimating and developing requirements and with testing.

Product owners are the ultimate deciders of the criteria that create customer value.

Daily stand-up

Among various Agile software development techniques, daily standups are becoming a ritual for the teams. Daily stand-up plays a very crucial role for better communication and effective collaboration among team members. A daily face to face meeting for 15 minutes will bring more transparency and visibility into the given project.

In order to avoid extending the conversations keep it simple and make sure the following questions are being addressed:

• What has been accomplished by far
• What obstacles are been faced
• What all is to be accomplished in future