Category: Agile and Scrum

[Event]Team Collaboration with Visual Studio Online

Today I’m running a new event in Central London (just in the very center, at SQS Group offices!)

And covering one of the topics of the year, Team Collaboration with Visual Studio Online.

For those that don’t know what Visual Studio Online is, just say that it’s not an IDE, it’s everything else. Visual Studio Online provides a set of cloud-powered collaboration tools that work with your existing IDE or editor, so your team can work effectively on software projects of all shapes and sizes.

Yes, of course it gives you version control (git or TFVC) but also Tools for agile teams such as Kanban, Scrum templates and Dashboards. It provides you powerful services like the new continuous integration system that allows you to build, validate and deploy into the a hybrid cloud and that offers an open and extensible integration with other platforms.

Do you want to know more?

Come to the event today here



In this session we will go through the Microsoft latest ALM Collaboration tools, covering how to plan and track work in an agile environment. This will be shown using one of the three templates that Microsoft provides for project management, Scrum, and we will see how to customize your Kanban boards, create dashboards and reports for anyone in the team (not only dev and test people). As Visual Studio Online is a Microsoft Cloud Service that is evolving every month, we will see also what’s just came new into VSO this year.

Who will this interest?

Anyone with a keen interest on Project Management, Work  Item Tracking, Capacity Management, Agile Frameworks.

Also BA, Devs, Testers and Ops that want to work in an Agile environment with a Continuous Integration and Continuous Delivery cadence.

We will cover the following topics:

-Project Management with Visual Studio Online
-Tracking work with custom Kanban boards
-Burndown, cumulative flow, capacity and other custom charts
– Collaboration between Management, Dev, Test and Ops.
Azure Active Directory, Office 365, Power BI
– Integration with Excel, Visual Studio, MTM and  Trello.

Come along to Moorgate on Thursday 24th September 2015 where Eduardo Ortega, ex former Microsoft  Evangelist, MVP and MCSD ALM professional, will be discussing Visual Studio Online and Team Foundation Server as ALM Tools.

[#ALM]Agile estimation, Story Points and Planning Poker

Agile estimating and planning is not an art, is a supernatural force that guide us and makes our lives miserable during a project execution with surrealistic delivery dates and weekends in company of our beloved fellas, sleeping in a blanket, near the computer, on a turn based programming day.

Estimation or the fine art of guessing is what is considered the biggest headache of every project and is because somewhere along the line people forget that high-level estimates are guesses, usually are bad and we tend to be optimistic about those.

At the beginning of a project we have too many unknowns that the degree of accuracy is far to be good. Only after building something you can get a better estimation and refine it with time.

So what we need is a way to make estimations that allows us to create budgets, make a plan for the future and remind us that our estimates are guesses, we are not storytellers and the complexities that we can find will be only estimated writing software.

Let’s focus on the steps to follow to make an agile estimation:

Keep it simple

We can think that the best way to do it is create individual stories and make an estimation for each one following the next guesses: Documentation, Analysis, Design, Programming and Testing. We are not so far from the truth but what really makes an agile estimation is relative sizing.

Relative Sizing

When we try to do absolute estimation, it’s impossible to success as we are getting our best guessing, for example, if I ask you what the sizes in cm2 of these two triangles are:

Triangle1Triangle2 You cannot truly say the size in cm2 of each but what you can say is that the blue one is 4 times the size of the blue one.

Triangle3  So estimating how bigger is the blue one respect to the yellow is easier for you, isn’t it? That’s because we are very good at estimating relatively. We call this “relative estimation” and it forms the corner stone of agile planing.

Once we know how fast the team can go and our stories are sized relatively, we can start setting expectations around dates and the velocity of our team will be set up.

Estimates are unit less

It is a common mistake to assign our relative measures to calendar days or hours. We don’t have a unit to track time! Different people think on different speeds.

What we can do is to make a point based system, and say.

1 pt = small task (maybe a day?)

3 pts = medium task (maybe 2 days?)

5 pts = large task (maybe a week?)


The way to work is to get 3 user stories of different sizes, one with a small estimation (1pt), another one relative to this one with 3pts, and another one big (5pts) just to establish a baseline, with small, medium and large size stories for the project.

Story points are relative values, not fixed. There is no direct correlation between hours and points. Story points are created by and are specific to the team that estimated them, will likely include a degree of complexity that is understood only by the team, and are not absolute. For example, we cannot say that a one point story is equal to 8 hours because stories on this range can vary depending on the tasks assigned to it and maybe can take 10 hours to complete them. Similarly, you cannot compare one team’s story points with another’s with any degree of certainty.

This is really great, but how we can make it even better?

Team Planning

It’s not about what you can estimate, is about what you and your team agree on estimating the value of a user story.

It works like this:


A team estimate is always better than one person.

Now, how to do this more effective and at the same time more fun?

Planning Poker

After you’ve chosen your unit of measurement and established your scale, it’s time to estimate.

Many of the Agile teams where I worked before uses planning poker to estimate the relative size of the stories. This is very popular among agile teams as the objective is to measure subjective estimations taking in consideration the expertise, experience and point of view of all the members in the development team. The key of planning poker is participation of everyone in the team, including designers, architects, developers, even that guy that is just playing Pac Man all day that will participate on the project as a QA tester, everyone.

There are plenty of panning cards in the internet or no so regular shops, even you can make your owns (we will see this in another post). Each card has one of the numbers in your chosen range of story points (1, 2, 3, 5, 8, 13, 21, etc.). Every participant is dealt a “hand” that contains the full range of available story points.

The cards in the deck have numbers on them. A typical deck has cards showing the Fibonacci sequence including a zero: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; other decks use similar progressions.

At the estimation meeting, each estimator is given one deck of the cards. All decks have identical sets of cards in them.

The meeting proceeds as follows:

  • A Moderator (Scrum Master), who will not play, chairs the meeting.
  • The Product Owner provides a short overview.
  • Each individual lays a card face down representing their estimate.
  • Everyone calls their cards simultaneously by turning them over.
  • People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then discussion continues.
  • Repeat the estimation process until a consensus is reached.

Because planning poker expresses estimates in points, it is ideally suited for estimating the product backlog. The sprint backlog, however, should be estimated in hours.

You can use planning poker at the beginning of any project and throughout its lifecycle as new information reveals itself, priorities change, and clarity surfaces.

I hope this post helps you to reconsider the way to make estimations for your projects and avoid bad situations within your team and with your customer.

–  Happy planing! –

Eduardo Ortega