Month: July 2014

[#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

[Enterprise Mobility]IBM and Apple together?

I’m still quite shocked with the agreement between IBM and Apple to sell and support iPads and iPhones in the enterprise but it is not a surprise.

IBM counts with more than 150 business apps and Apple has some of the best consumer devices with no enterprise integration at all. Microsoft has a great combo of devices + consumer apps + commercial apps + enterprise integration, but still needs the “cool factor” of Apple or the pricing of Android devices.

Having said that, I think this new friendship is a very serious matters as IBM services are really good (despite they are bloody expensive) and iPads and iPhones ara also very good devices as well.

We have to remember that IBM was ranked as a leader in Gartner Magic Quadrant for Mobile application Development Platforms this year and ranked second just after Microsoft in the ALM Quadrant.

Amongst the main Mobility Enterirpse products on IBM we have the new IBM Worklikght Platform, the IBM mobile services for Bluemix, the Cloudant, the IBM WebSpehere MQ and the IBM MessageSight, and these are only some of the so many services that IBM is providing for Enterprise Solutions.


Still, for me Microsoft Mobile Strategy is the best right now but if Apple and IBM begin to work together… interesting times are coming 🙂


Some references:

[#ALM]Why we use agile methodologies?

 In one of my favorite books , I read something concerning:

“In the Standish Group’s 2011 CHAOS Report found that more than half of software projects conducted between 2002 and 2010 were either de- scribed as challenged or complete failures; just 37 percent were classified as successful”

21% of these projects failed and 42% were challenged, and this is the real challenge.

We are wasting money, resources and time on bringing solutions and applications to the market just because we are not using and agile way to work.
Why are you not using AGILE? There are not excuses for don’t use agile methodologies anymore, and it is not anything new, as AGILE methodologies have been living with us during the last 10 years.

Still, when I’m visiting many of my costumers I see unstructured teams, following old methodologies like Waterfall or dinosaurian ones like CMMI in short projects. But when you have to talk about have a model adaptable, fast, responsive, incremental, collaborative and when you are realizing that 1 of every 2 projects that you are delivering have delays, causing low morale to your team and also you are struggling adapting to the constant changes from your customer,…. then is when you have to rethink on your strategy and maybe move to an AGILE approach.


Use an AGILE methodology like Scrum, doesn’t mean that we have to forget writing the documentation or do the planning on demand but it means that you have to be focus on the most important part of the project, the software.

We have to go back some years to 2001 when the Agile Manifesto was introduced. Since then, the Agile Movement, with all its values, principles, methods, practices, tools, champions and practitioners, philosophies and cultures, has significantly changed the landscape of the modern software engineering commercial software development in the Internet era.

The meanings of the manifesto items on the left within the agile software development context are:

  • Individuals and interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
  • Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.
  • Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
  • Responding to change – agile development is focused on quick responses to change and continuous development.

The Agile Manifesto is based on twelve principles:

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Close, daily cooperation between business people and developers
  5. Projects are built around motivated individuals, who should be trusted
  6. Face-to-face conversation is the best form of communication (co-location)
  7. Working software is the principal measure of progress
  8. Sustainable development, able to maintain a constant pace
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

There are hundreds of thousands of developers world wide  using Agile methodologies since then. There is no the right one, each one will be better for you and your team depending on your way to work, projects, timing, but all of them share the same principles.

Well-known agile software development methods and/or process frameworks include:

Just to finish these remarks, let’s introduce briefly ALM, as in Wikipedia is explained:

Application lifecycle management (ALM) is the product lifecycle management (governance, development, and maintenance) of application software. It encompasses requirements management, software architecture, computer programming, software testing, software maintenance, change management, project management, and release management.

This means that Modern Apps need a Modern Lifecyle, and for me here there is only one Winner, Visual Studio.

First) Because Microsoft is providing you a full set of integrated tools that cover the whole development cycle, and yes, INTEGRATED. It means that you don’t have to be installing tools from different vendors but also, if you want to install them, they will be integrated with the Visual studio Suite.

For example, I remember some of my projects in my previous company, Symphony Teleca, where we were implementing Scrum using “Open Source/Non Microsoft/Almost free” tools. For the source repository we used GIT (very good btw, truly recommendable), JIRA, Sharepoint and txt files 🙂

Our main IDE was Visual Studio, which you can integrate manually with GIT, but not with JIRA (there is a plugin from atlassian but very immatture and when you want to go for something more effective they are hidden costs on this “freeware” version), and the rest of the systems are disconnected. The TDD environment was isolated of the management and reporting tools and the team was also working in a “ghost” collaborative mode.

Nevertheless, opting by the Visual Studio approach, you get the full ALM cycle covered:
–  Set up: 
Set up TFS, create a team project, and add team member accounts.

–  Code: Share and build your code using Team Foundation version control (TFVC) or Git.

–  Work: Plan projects, track work, collaborate as a team, and report progress.

–  Build: Set up your on-premises build server and define your build processes. Or, set up continuous integration builds using Visual Studio Online.

–  Test: Test your application..

Also, Visual Studio includes some of the most common AGILE frameworks templates included like Scrum, CMMI, and Agile. But we will talk about TFS and Visual Studio in other posts.

Here some good readings about Agile methodologies to start the week with something new, I hope you like it:


 The Scrum Guide


Happy planning!
Eduardo Ortega



–  Scrum (Software Development)

–  Kanban for TFS

–  Kanban (Development)

–  TDD

–  Agile Manifesto





Visual Studio 2013 Update 3 RC

It has been a couple of weeks since Visual Studio 2013 Update 3 RC was available for download, so I guess that many of you already have the chance to play with it a bit, but just let me go through the new capabilities and features for those that didn’t explore it in deep.

First say that as part of the continue integration that Microsoft is doing with Visual Studio, we have had a bunch of improvements during the last 9 months. Most of these like the Update 2 were put in place to bring us access to the new Universal Apps and the support to Multi-Device Hybrid Apps for Visual Studio.

You have to realize that Microsoft is doing a lot of efforts bringing the multi-platform and universal development to Visual Studio, for example, with the Multi-Device Hybrid Apps pluggin you will be able to develop hybrid apps that run on iOS, Android, Windows and Windows Phone, using a single project based on HTML and JavaScript.



With Visual Studio 2013 Update 3 (RC), Microsoft is bringing you more new features and improvements:

  • CodeLens
  • Code Map
  • Visual Studio IDE improvements
  • Windows Store Debugging
  • Managed Memory Dump Analysis
  • Graphics Debugging
  • Performance & Diagnostics Hub
  • Test Case Management
  • Release Management
  • Sharepoint Apps and ClickOnce

Between the Visual Studio IDE improvements you can find also the multi-monitor configuration for Windows 8 apps debugging and a configuration option to put CAPS or no caps menus in the IDE.

We will be visiting one by one all these new features but let’s talk for a second about one of my favorites and also the most simple one, it is the Multi-Monitor configuration with Windows Store Apps.

When debugging a Windows Store app with a multi-monitor configuration, we used to have problems with the screens dragging all the time the app to the secondary screen, now, Visual Studio will remember which monitor your app was last run on. Example:



Let’s review all these features in further posts but in de meantime download the Update 3 RC and happy coding!

Eduardo Ortega