Category: ALM

Reporting on TFS

Today during the Deep dive in Visual Studio and MTM course we were covering the types of reports that can be produced in TFS. Either for tracking your tasks or your tests progress, these reports are produced from the same place and with the same mechanism. Let’s take a look to the next picture:

As we all know, the SQL Server database that is in TFS is in charge of storing and producing the right KPIs for our reports. Most of the information we query is directly extracted directly from the database where our project is hosted (our project collection DB). But most of the reports are produced directly not from the project DB but from the OLAP data cube that is managed by SQL Server Analysis Services.

So said that, we have two extra Data Bases, one is the OLAP Cube, TfsAnalysis data base, that is mainly use to generate reports in Excel or to export reports to SharePoint wherever you have an integration with it.

The other database, TfsWarehouse, is being used to generate reports through SQL Server Reporting Services, which give us the chance to generate also our own reports using the Report Designer tool. This reports are easily accessible through the Web Access of our team portal or from our Team Explorer in Visual Studio.

Either for TfsAnalysis or TfsWarehouse databases, you should have permissions to them both in order to create this reports.


SQL Server Reporting Services

When you finally get access to SSRS, you would be able to access to the folder above represented, and, depending on the project template that your team is using for the project, you will see less or more reports. But remember, the report builder is there!

Some of the reports are the next:

  • Test and bug reports

    • Test Case Readiness
    • Test Plan Progress
    • Bug Status
    • Bug Trends
    • Reactivations
  • Project Management Reports:

    • Backlog Overview
    • Release Burndown
    • Sprint Burndown
    • Velocity

All these reports and more are explained here

Probably the test case readiness is one of the most detailed and spectacular, showing us the next information:

This is an extended version of the simple chart that we usually take from the Microsoft Test Manager (Plan tab, Results menu), where we can analyse the Test Result Summary of our tests executions by tester, by suite, by configuration and answer to questions such as:

How much testing has the team completed?

How many tests are left to be run?

How many tests are passing?

How many tests are failing?

How many tests are blocked?

Why tests are failing?

Are new issues going into production?

Is there any regression on the failing tests?

Last but not least, another way to create reports in TFS is using Microsoft Excel.

These awesome pivot tables can be generated from either the Team tab in Microsoft Excel or from Visual Studio (straight from a query).

If you are creating the report from Visual Studio Team Explorer, you basically have to look for the query you want to use to generate the report, and then right click and create report in Excel.

If you decide to create the Report from the OLAP Cube, in Microsoft Excel there is a tab called “Data”. There you will find an action called “From other sources” where you can select “From Analysis services”

After you chose this option, a wizard will be introduce to you:

  1. Connect to the DataBase server
  2. Select DataBase and Table (Tfs_Analysis will be ours)
  3. Give it a name and point it to our file
  4. Report will be generated

I hope this blog post has thrown some light on what reports are available in TFS and do not forget… In terms of having these reports, you have to generate the data first! So make sure you create your work items such as tasks, user stories, test cases, and others properly or reports will be useless J


Eduardo Ortega

FREE Upgrade to Visual Studio Enterprise with MSDN!

There is no better time to get ready for the release of Visual Studio 2015. The new Visual Studio is coming in May 2015 and the prices have been reduced dramatically!
When you upgrade from Visual Studio Professional or Visual Studio Test Professional to Visual Studio Premium, the price is cut to 50%! And also get a free upgrade to Visual Studio Enterprise with MSDN automatically when Visual Studio 2015 gets released.

The offer is only valid for 2 months, expiring on June 30th so hurry up.
But there is much more. Visual Studio 2015 license system has changed. These are the versions that we will have now:

  • Visual Studio Community

    • Integrated Development Environment for building Web, Windows Desktop and cross-platform iOS, Android, and Windows apps
    • Ecosystem with thousands of extensions to choose form the Visual Studio
    • Free for open source projects, academic research, training, education and small professional teams
  • Visual Studio Professional with MSDN

    • Professional developer tool for building any application type
    • Powerful features to improve your team’s productivity such as CodeLens
    • Improve team collaboration with Agile project planning tools, Team Rooms, charts and more
    • MSDN subscription benefits including access to core software for dev/test, Team Foundation Server, Visual Studio Online Basic, $50/month in Azure credits, training and support.
  • Visual Studio Test Professional with MSDN
  • Visual Studio Enterprise with MSDN

    • End-to-end solution for your development teams, including the most feature-rich Visual Studio IDE for working on any type of project
    • Build quality applications at scale with advanced features such as Load Testing, automated and manual testing and new IntelliTest capabilities
    • Manage complexity and resolve issues quickly with features such as Code Map and IntelliTrace
    • Enhanced MSDN subscription benefits including comprehensive access to software for dev/test, Team Foundation Server, Visual Studio Online Advanced, $150/month in Azure credits, training and support

Customer price has changed as well:

If you have You will get New customer price
Visual Studio Community Visual Studio Community 2015 Free
Visual Studio Professional with MSDN Visual Studio Professional 2015
Your Visual Studio Professional with MSDN
subscription will continue without change
Visual Studio Premium with MSDN Visual Studio Enterprise 2015
Your subscription will be upgraded to
Visual Studio Enterprise with MSDN


Here you can find a comparison between the different versions of Visual Studio, including the Visual Studio Test Professional (that is the most relevant product for many of us).]


Team Foundation Server 2013 Access Levels

*Info updated here:

The amazing world of licenses…when to use them, how to use them, how many computers, how many users, how many services available, on premises or online… These are few of the many questions that I receive every time a Dev or Test teams need to increase its number or its disciplines.

Let’s explain first how it works for those users that work with Team Foundation Server 2013 (the On-Premises server).

TFS 2013.3 Access Levels

First, a user, whatever kind of user is, needs to access to TFS2013 Update 3, so we need to specify which features need to get accessible. For that we have 3 levels (more info here):

  • Limited (Stakeholder access level)

    • View My Work Items
  • Standard (Basic access level)

    • View My Work Items
    • Standard Features
    • Agile Boards
    • Backlog and sprint planning tools
    • Chart Viewing
  • Full (Advance access level)

    • View My Work Items
    • Standard Features
    • Agile boards
    • Backlog and sprint planning tools
    • Request and Manage Feedback
    • Test case management (including running tests)
    • Team rooms
    • Agile Portfolio Management
    • Chart Viewing
    • Chart Authoring

Now that you know more about the licensing, let’s differentiate the licensing on TFS2013.3 from TFS2013.4 and Visual Studio Online.

In TFS2013.3 the access levels were Limited, Standard and Full.

In TFS2013.4 the access levels are Stakeholder, Basic and Advance.

In Visual Studio Online the levels are Stakeholder, Basic, Professional, Advance and MSDN Subscribers.

TFS2013.4 Access Levels

Let’s see now how the licensing changed from TFS2013.3 to TFS2013.4:

Access level

License required


TFS client-access license (CAL) or Visual Studio Professional with MSDN subscription


One of these MSDN subscriptions: Visual Studio Ultimate with MSDN, Visual Studio Premium with MSDN, MSDN Platforms, or Visual Studio Test Professional with MSDN.


No license required. Assign Stakeholder access to customers or stakeholders that you want to collaborate with but who aren’t on your team.

It means that the Stakeholder level (previously called Limited), will allow you to create Workitems (such as Bugs, Test Cases, Requirements, etc) but now, on the Update 4 for TFS2013, we have some extra features:

Stakeholder access level:

  • View and edit all work items (not only yours)
  • Standard features
  • Agile boards
  • Basic backlog and sprint planning tools
  • Agile Portfolio Management

If you go for the Basic access level (you would require a CAL or a license of VS Professional), you will get the next features access:

Basic access level (all stakeholder’s plus…):

  • Chart viewing
  • Build
  • Code
  • Administer account
  • Advanced home page
  • Advance backlog and sprint planning tools

Advanced access level (all basic’s plus…)

  • Chart Authoring
  • Request and manage feedback
  • Test case management
  • Team rooms
  • Advanced portfolio management

Visual Studio Online Access Levels

And last but not least VSO. If you don’t want to host the TFS server on your premises or just you want to avoid all the set-up of servers, SQL Server Databases, etc. Maybe the best option is to subscribe to an on demand service called Visual Studio Online (previously called Team Foundation Service). This service allows you to get licenses on demand and monthly, so you will save a considerable amount of money. Right now you can’t have divided your infrastructure half on premises, half on the cloud, so that means that your online users will work on team projects hosted on the cloud.

VSO features are slightly reduced in comparison to TFS (like reporting or SharePoint integration) but most of the features are available!

Let’s go through the features accessible through the different access levels

Stakeholder access level (free):

  • Work item tracking, queries, tagging
  • Alerts
  • Agile planning boards and backlogs
  • View Iteration and capacity planning
  • Portfolio management boards and backlogs
  • View query based charts 
  • Provide feedback
  • Track test progress and charts

Basic access level (5 free and $20/month new ones). All stakeholder access plus:

  • Team chat
  • Git repositories and TFVC
  • Work with Xcode, Eclipse, IntelliJ and others
  • Code Reviews
  • Enterprise Scale
  • Full Build and Deployment features
  • Web-based test execution. Test runner
  • Administer accounts, users, teams and projects structure

Professional access level (includes stakeholder and basic access levels). $45 per user per month.

  • Includes Visual Studio Professional

Advanced access level (includes stakeholder and basic access levels). $60 per user per month.

  • Request and manage feedback
  • Test planning: create test plans
  • Test authoring
  • Test suite management
  • Test tracking

As you can see it’s slightly different the On-Premise Server than the On-Line Services but in practice, this would be transparent for your developers, testers or team leads.

For more information follow the links below.

Happy licensing!

Eduardo Ortega


VSO Matrix:

Visual Studio Versions:

Work as a stakeholder:

Visual Studio Online Pricing:

Pay for users accessing your account:

Visual Studio Online Basic:

Enterprise agile – Integrating Project Management and Software Development Teams

Management vs Development, they look like 2 worlds apart right? J Yes they are indeed, but this doesn’t mean that they can’t exists together on the same world and be interconnected. If you want to know more about how to bridge the collaboration gap between their project management offices and their software development teams continue reading…

I still remember those days, years back, where the Projects Manager used to spend an uncountable number of hours with the Team Lead catching up on the status of the projects, delivery dates, impediments and other matters related. It was such a show to see the TL trying to explain the Management what an iteration and user stories were. My manager used to leave these meetings with a terrible headache and long face, so the next action were to come to desks and ask us all the details about when, how and why of the releases we had on the pipeline.

This rings a bell for you right? This continuous reporting is good and bad at the same time, this makes the transparency to increase but the amount of time lost in reporting is huge. What if Project Managers and Software Development Teams can use the tools that they prefer, work at the level of precision that supports their needs and share information organized, transparently and immediately?

To enable this flow of data you can have two options:

Option A – TFS and Project Server Integration: On the management side (usually the PMO) install the Team Foundation Server Extensions for Project Server on the application-tier or web-tier servers that run Project Server that will participate in data synchronization.

With this, Project Managers would be able to use Microsoft Project Server to access up-to-date project status and resource availability across software teams using Team Foundation.

This integration enables data to flow from work items in Team Foundation Server (TFS) to tasks in enterprise project plans in Project Server.

Option B – Team foundation plug-in to Microsoft Project: This scenario doesn’t require a Project Server, just Microsoft Project but it is a very limited scenario. For example:

  • Supports mapping a task field in Project to a field in Team Foundation but Tasks are not bound to work items
  • Project plans are bound to Team Foundation server
  • For resource tracking, hours are rolled up in Project but not in Team Foundation, so resources are not rolled up either
  • View across multiple enterprise project plans and reporting, portfolio optimization and demand management are excluded in this operational model


Oh yes! Now we are talking J

Let’s take a look at the internals and how this works.


As you can see you can use MS Project to open a project plan, manage and track the work across all your backlogs and teams and even control the timesheets and the resources usage. This will be fully connected through a series of mappings to TFS so the development team will see the changes reflected on their dashboards when they will access through the team web portal or Visual Studio Team Explorer.

As well every time the development team make a change on the user stories or the work items, this will be reporting directly to the project server (if changes applies).

The process flow for Top-Down Planning on a regular project is represented on the next figure:

  1. The Project Manager define the deliverables, features and requirements in the project plan (Project or Project Web App – PWA)
  2. Save and publish the project plan to Project Server
  3. Each time something is published from Project Server, the sync engine performs the right mappings between the item types of Project Server and the work items in Team Foundation Server, binding them both.
  4. The team lead opens the Team Explorer or the Web Portal to review the deliverables with the Team
  5. The team lead break down into tasks the user stories and features that the Project Manager established in the Project Plan
  6. And assigns a resource to each task
  7. Saving it on the Team Foundation server and publishing it back to the Project Server for the Project manager review
  8. The Project Manager reviews the progress of each deliverable and adjust the schedule based on the updated information and
  9. A baseline is established, so it will be able to track progress against the baseline.



Usually you will find scenarios where to integrate TFS with Project Server 2010 or Project Server 2013.

There is no a big difference between using 2010 or 2013 but small differences on the authentication and security:

For example:

  • On Project Server 2010, during the set up you must install all the cumulative updates on all Web Tiers and on all App Tiers in the server farm.
  • On PS2010, the Classic Mode Authentication is the only allowed authentication mode.
  • Security: On PS2010 you manage your PS security through customizable security groups where in PS2013 you can use SharePoint Permission Modes to control user access to sites and projects.

So this will be the typical architecture:

/benefits of integrating TFS with Project Server/

  • Go deep into portfolio execution, alignment with strategic objectives, and resource usage of software development projects.
  • Automate the sharing of project information across teams whatever methodologies are using (waterfall, agile, cmmi,…)
  • Enable development and project-management teams to collaborate through project timelines and progress using tools such as Visual Studio, Microsoft Project, SharePoint and Excel.


/How the Project Manager will see this in MS Project/

Basically like this:

To mark a new deliverable as an item to synchronize with Team Foundation Server, we will have to set the Publish to Team Project property to Yes and set the Work Item Type to the right value (p.e. Requirement, task,etc).

All we need now is to save and publish the project plan to the Project Server and the synchronization will be triggered.

/How the Team Lead will see this in the Team Explorer/

If the team lead opens the Team Explorer and goes down to the Work Breakdown to check the work items.
There the new requirements and tasks will be visible and we will be able to edit them and add extra information like for example the effort estimation, the priority, change the assignation, etc.

Also, any change made from here will be synchronized with the Project Server as well, as for example, imagine that we are working on an specific work item and once we finish it we want to report that the Remaining work time for this Work Item now is 0. Just saving the Work Item from Visual Studio the Project Manager will see the submission request on the PWA portal as this:

Where the task update to get approved will have the next details:

And therefore will be updated also in the Project Plan.

/Wrapping up/


It can be a bit messy if you don’t look at the picture from a general view, as you have to know a bit how the project management usually work and how the development team operates. What this integration is offering is a way to communicate both teams, save time, be transparent and improve the internal process of control.

I recommend you to follow these Hands On Labs to know more about the integration of PS with TFS and if you want to go deeper on it, you know where to find me J


– May the plan be with you –

Eduardo Ortega Bermejo



Team Foundation Server and Project Server Integration Virtual Machine:

Demonstration videos:

Hands On Labs and free book for TFS 2012. How to build a release pipeline?

For those that are into SDLC and ALM, here you have a fantastic guide. No matter what size business you have, customers now expect features such as real-time customer service and frequent releases.

The goal of this guide and HOLs is to provide you an excellent guide to the principles and practices of continuous delivery.

By continuous delivery, we mean that through techniques such as versioning, continuous integration, automation, and environment management, you will be able to decrease the time between when you first have an idea and when that idea is realized as software that’s in production. 

You will find this book an indispensable resource:

PDF and epub: Building a Release Pipeline with Team Foundation Server 2012
Kindle (Mobi): Building a Release Pipeline with Team Foundation Server 2012

Paperback versión (Amazon): Building a Release Pipeline with Team Foundation Server 2012

– Happy planning!



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

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