Category Archives: Agile

Microsoft’s Azure DevOps – Planning Poker Estimation Tool

Although I’ve been a huge fan of PlanningPoker.com since 2011, my Scrum Product team consisted of more than five members, and their Free Membership allows up to 5 users. The team I was working with had just started their agile transformation and was trying out aspects of Agile / Scrum they wanted to adopt. They weren’t about to make the investment in Planning Poker for estimations quite yet, so I stumbled across an estimation tool as a free add-on to Azure DevOps.

Microsoft’s Azure DevOps solution is both a code and requirements repository in one. Requirements are managed from an Agile perspective, through a Product Backlog of user stories. The user story backlog item type contains a field called “Story Points”, or sometimes configured as “Effort”.

Ground Rules – 50k Overview

All team members select from a predetermined relative effort scale, such as Tee Shirt Sizes (XS, S, M, L, XL) or Fibonacci sequence (0, 1/2, 1, 2, 3, 5, 8, 13, 21, 34…) All selections of team members are hidden until the facilitator decides to expose/flip all team selections at once. Flipping at once should help to remove natural biases, such as selecting the same value as the team tech lead’s selection. After that, there’s a team discussion to normalize the value into an agreed selection, such as the average value.

Estimate New Session

Integration with Azure DevOps

The interesting thing about this estimation tool is you can explicitly select stories to perform the effort estimation process right from the backlog, and in turn, once the team agrees upon a value, it can be committed to the User Story in the Backlog. No jumping between user stories, updating and saving field values. All performed from the effort estimation tool.

Agile Mind Games – the Psychology of Scrum

Team Effort Estimations Are Critical to Accurate Velocity, Maximum Productivity, and Team Building.

The team tech lead may provide an effort estimation with little or no input from the developers and/or testers doing the work.

If the tech lead vocalizes his/her effort estimation…

  • BEFORE the developer who will be doing the work, the developer may feel pressured to agree with the tech lead’s estimate.
  • lower than the developer’s guestimate, who will be doing the work, this might create social friction and inaccurate velocity.
  • WITHOUT a collaborative approach, a comprehensive estimation may be ruled out, such as consideration for not only dev. and test., but infra (configuration management, i.e. build & deploy) and other effort costs.

Using tools like Planning Poker, where all estimations are revealed at once helps the team appear to not contradict one another. The negotiation process occurs after all teammates flip their cards at once. Derives better estimates with more perspectives not factored in based on a single Tech lead providing the estimation.

Transparency and Scrutiny

Many “hands-on” project/product stakeholders want maximum transparency into the current state of the product regardless of the duration of the sprint (e.g. 2-week sprints),   Typically, a pulse on the product at two-week increments satisfy most.

Some of the agile, change management tools such as Microsoft Azure DevOps offer dynamic graphing and reporting.  Product stakeholders may be provided dynamic dashboards, that include Burn Down, and Burn Up charts based on the sum of effort from user stories (i.e. product backlog items).  At any given time charts can predict velocity, and based upon the outstanding, total effort estimation, can chart a course to the next release.

Meaningful burn up and burn down charts rely not just on accurate effort estimations, but the people who are assigned these user stories constantly update the status of these stories, e.g. New; In-Progress; In-Review; Done. Countless times I’ve seen team members update the user story status the day before the sprint close/demo, from New -> Done.  This habit gives any product stakeholders a false view of the product within a sprint.

Another challenge and opportunity with Transparency and Scrutiny within a given sprint, is making sure each user story has one or more (child) tasks.  Defining tasks provides a wealth of opportunity, such as naming all of the tasks to complete for the story, e.g. database tasks, UI tasks, etc.  If the tasks are itemized, they may also be assigned to multiple team resources, and show a delineation of labor.

Sticking with the Azure DevOps tool, Tasks have a default field, “Remaining Work”.  This field may express task work in hours or days, the unit of measure. In the beginning, tasks are populated with the total task guesstimate of hours. Each day the person assigned the story task may draw down on the task to incrementally show progress within the task and correlating story.

Task, Work Remaining field must be relentlessly updated across the Backlog in play or else it will create more harm than good. At this level of scrutiny on tasks are amorphous and will be challenging to garnish any projected value.

The Abominable Blocker

What, you can’t figure it out on your own?

The dreaded blocker has the ability to stop a Scrum team in its tracks. The term Impediment used synonymously with the word Blocker, has an innocuous sounding sentiment. Your Scrum team may use either, perhaps a less severe issue merits an Impediment?

The Kanban / Scrum board may have a column in the workflow called Blocker, which should fixate your team on helping to remediate that Blocker. Our Daily Scrum of 15 min may focus on Blockers as they have been isolated in our workflows.

Conquer the blocker before it conquers you!

Applause, Applause

Closing and Demo for Sprints should follow healthy applause from the team, including Stakeholders and Product Owner. Positive reinforcement of a job well done. We’ve completed what we committed to complete, should be followed by applause. We should take a moment to soak in the feedback.

Pass the Mic

For those of us on the Scrum team who are introverts and actively look for ways of dodging opportunities to speak, this one is for you. During Daily Scrum, pass the facilitation mic around where everyone gets an opportunity to facilitate per stand up.

Allow all people within the team an opportunity to demo the “Done” user stories on sprint close. It’s not to break folks out of their shell, it’s to impart a sense of pride in the work accomplished, and truly resonate the one team mentality.

Disclosure: the opinions provided are my own and do not reflect that of my clients, or anyone I represent.