View from the Enterprise


Software development still has a number of stages, steps, tools, platforms and just stuff that needs to be done. This is not getting simpler. In fact as the world of software progresses these things become more complicated through size and scale. We are using a number of tools that did not exist until recently as part of our ecosystems.

The Integration Hub

Along with this we still have a need to understand the state of play for our development and support operations. This state is represented in a number of different tools and processes and can be spread over organisations that number in the hundreds or larger. These projects are scaling and the agile world is also scaling. The questions of how to keep track of events in a way that is manageable and transparent reflects itself in the portfolio layer in the Scaled Agile Framework® (SAFe®), Product Group in LeSS, as well as in DAD. VersionOne acts as an integration hub to bring all these different areas together as shown in the diagram below.









As an integration hub, VersionOne has access to information from tools which truly are across the lifecycle of software development. All of the information from this integration hub can be combined into reports which tell a complete and rich picture of the status of the software development story for any particular value stream or portfolio within the enterprise.

As part of requirements, we can use PPM tools to start programmes and projects with information about a number of main concerns such as:

  • Strategy and Investment Funding
  • Governance
  • Programme Management

And includes subjects such as:

  • Pipeline Management
  • Resource Management
  • Change Control
  • Financial Management
  • Risk Management

PPM often is the starting point for work in an enterprise. Work is at hand to make PPM better aligned to agile values, but that may take time. However starting with the big concerns of PPM and moving across the software development landscape we also see:

  • Enterprise Tools
    • Defect Management
    • Sales Knowledge
  • Requirements
    • NFRs
    • Needs
    • Detailed Acceptance Criteria
  • IDE
    • Checkins
    • TDD Results
  • Source Control
    • Checkins
    • Versions
    • Branches
  • CI (Build)
    • Build Numbers
    • Build Quality
    • Test Results
  • Test
    • BDD
    • Acceptance Tests
    • Test Automation Runs and Coverage
    • Test Pass/Fail (Not to be confused with Quality)
  • CD (Deploy)
    • Where is my build now dude
    • What is the status of my environments
  • Team Tools
    • Team Backlogs
    • Team Velocity
    • Burn Down for Current Sprint

The above is only an example of the information generated by each area of the programme. The challenge to enterprises is to see this at the enterprise level. Each tool provides a view into an aspect of the programme or project and as the diagram show can also share this view with VersionOne, sort of an aspect oriented view of the enterprise.

Analytics and the Data Mart

Information made available through the integrations is placed into the VersionOne data mart. This is available to all of the main tools provided such as:

  • Agile Reporting
  • Agile Analytics
  • Agile Visualisation
  • The Data Mart itself

The data mart is populated by data which can be sourced from VersionOne itself or from any of the connected integrations. Once we have access to all of the information shared through the integration hub, what then!

The agile reporting feature has a large number of standard reports that are all available for customization. The usual advice is to find one that is close to what you are looking for and customise a copy of this report. This allows a degree of access to the data held. But there is more!

The visualisations include the scorecard features that allow a fast and intuitive means for grasping the basic health of a programme with drill down capabilities as needed to explore in more detail. This solution provides a scrolling set of scorecards that allow a continuous monitoring of the portfolio to be presented. These can also be customised somewhat. Then what?

The analytics feature can provide a series of customised dashboards for reporting and situational awareness. These dashboards can be customised and user private dashboards can be maintained as desired. These dashboards access the data mart and are good for providing the awareness needed on a daily basis.

Within the analytics you can construct grid views of the data in that data mart, including data items that have been added through the integrations. These views can be exported as spread sheet data for consumption in other places.

In addition reporting features are available to create reports using data in the data mart. These reports can be shared by email in a number of formats such a PDF or Excel. This means that recipients of these reports do not consume VersionOne license counts. This ability to export using external formats is available throughout the Analytics feature.

If these features do not deliver what is needed then the data mart can be accessed by external tools including Business Objects, Crystal Reports, Actuate, Cognos or LogiXML.


VersionOne integrates a wide range of tools and platforms and creates the data mart from these platforms and data managed directly from VersionOne. This data mart can then be accessed by a wide range of tools provided through the VersionOne data mart.

This approach allows an enterprise to exploit the fact that the most complete set of data for its development organisation is in the VersionOne integration hub. The value in this data is through the information that can be derived and shared from it, while supporting decision making throughout the enterprise from board to team.

About the Author

versionone-coaches-mike-carew-150x150Mike Carew
SAFe Program Consultant, Chartered Engineer, IC Agile Certified Professional

Mike Carew is focused on helping European organizations adopt the VersionOne platform on their agile journeys. Mike has been involved in every aspect of software business including support, development, operations, management and services. At HP he established the EMEA agile practice. Mike has coached teams and corporations from the FTSE 100, non-listed and government. He brings a pragmatic approach to coaching since he sees that there is no such thing as a one size fits all.

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in Agile Champion, Developer, Platform, Product Owner, Program Manager, Project Manager, QA Tester, Roles, ScrumMaster, ScrumMaster | Leave a comment

TeamSync: Building a Bridge Between Dev & Product Management










In today’s face-paced environment where time-to-market is critical, portfolio and program managers recognize that they need to evolve – that they need better visibility, greater strategic alignment, and improved high-level planning and progress management. But many enterprises have not successfully provided these capabilities because doing so would require introducing new tools and processes, thereby disrupting their development teams.

So how do you provide executives, program managers, and product managers better visibility, greater strategic alignment, and improved high-level planning and progress management without disrupting the development teams? You adapt and coexist.

Adapt and Coexist

You adapt by accepting that teams often work better when they are empowered to leverage the tools that best meet their needs. As an organization, it may be in your best interest to align with your development teams and let them keep using the tools they are most comfortable using.

That being said, you still need to understand and manage the work that the teams are doing across your organization, and do so in the tools that best meet your needs, so you have to coexist.

You can coexist by building a bridge between leadership and development, letting your development teams use the tools with which they are most efficient, while at the same time using your enterprise agile platform tools to pull in the data from these teams, roll it up, and provide everything you need to effectively manage your enterprise portfolio.

Building the Bridge

Building this bridge between the tools development teams are using and the visibility that portfolio and program managers need doesn’t have to be difficult. VersionOne is introducing a new type of integration tool called TeamSync™. TeamSync provides portfolio and program managers with visibility into the work that their teams are doing without disrupting the teams’ current agile tooling and processes.

TeamSync is designed from the ground up to allow VersionOne to coexist with other agile team tools while providing accurate and near-time roll-up of the features on which the agile teams are working, including their backlog items, estimates, status, and effort. With TeamSync, agile teams can continue to use VersionOne or Atlassian® JIRA® at the team level allowing that information to seamlessly flows up to the Enterprise, Portfolio, and Program levels in the VersionOne Enterprise Agile Platform.

Find out more about how TeamSync can help you gain the visibility and insight you need to make better decisions and understand progress with minimal disruption to your development teams.

VersionOne is a registered trademark and TeamSync is a trademark of VersionOne, Inc.
Atlassian and JIRA are registered trademarks of Atlassian.

Posted in Release Announcements | 1 Comment

Budgeting in an Agile World

Agile Budgeting-01








Agile budgeting can be a blasphemous term. It’s not uncommon when the subject of budgeting is brought up to hear “We’re agile. We don’t need budgets.”

While it may be true that an agile team itself doesn’t need budgets, it is almost certainly true that the company housing that agile team does. Businesses need to understand, project and in many cases contain costs. Budgeting provides the mechanism to do that.

Agile Budgeting

Traditional software development approaches budgeting at the project level. Each project up for consideration must have a defined cost, benefits and the all-important ROI. The projects are approved based on the ROI or some combination of factors (hopefully *not* including “Who has the loudest voice?”) and the projected cost is turned into the approved budget for that project. ‘Resources’ are amassed and the project work begins.

Many organizations have leveraged agile to ease that process. A nice simple agile approach means one does know the ongoing costs of the development team(s). By feeding in a stream of prioritized initiatives or features to stable teams, the overall costs are well-known. It’s just the per-initiative or per-feature cost that may be less well-known (and many an agilist would say that is rightly so).

The Scaled Agile Framework® (SAFe®) recognizes some of the inherent issues with project-based budgeting and proposes an improved form of budgeting at the Portfolio level (far away from individual agile teams, mind you).The SAFe approach essentially allocates funding to various Agile Release Trains (ART’s) to allow for budgeting at the high level while leaving feature decisions in the hands of those who are most knowledgeable about the value and priority of the options. It also describes the potential for assigning budgets to specific portfolio items that might reach out across ART’s and Programs.

When we interviewed customers about their current and desired budgeting practices with respect to product development, we found one consistent theme: variety abounds. We found those who espouse the approached learned from their SAFe training. We found those who practice old-school project-based budgeting. And we found those who would prefer to utilize strategic themes as a means to budget development capacity. Budgeting clearly remains a practice with quite a bit of inherent variety so a solution for it must be adaptive.

In the Summer 2015 Release, VersionOne takes an initial step towards supporting budgeting within product development with the introduction of Enterprise Budgeting. This new capability is not so much a means to replace the financial people and systems, but as a mechanism to bring the budgets closer to the development organization’s world. This allows quicker cycles in planning and quicker decisions when options must be weighed. As the variety of current market practices indicate, this is an area that is sure to continue its evolution.

Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.

Posted in Agile Champion, Product Owner, Program Manager, Project Manager, Release Announcements, Reporting & Analytics, ScrumMaster | Leave a comment

Drive Better Version Control Practices with CommitStream™

We’re very excited to announce the general release of CommitStream™. Initially released in limited beta in our Winter 2015 release, CommitStream is now available in Catalyst, Enterprise, and Ultimate editions. At launch we will be supporting GitHub and GitHub Enterprise.

What exactly is CommitStream?

CommitStream is a native version control integration within VersionOne that enables teams to implement best practices around continuous integration and continuous delivery. It streamlines the connection to version control tools and provides teams a real-time view into the code commits that are taking place in their development cycle. Teams can view code commits related to each VersionOne workitem in a single place. A dedicated panel within each workitem will present commit data including author, branch, repository, and commit comment. This added visibility provides teams a real-time, view of code changes and their relation to the delivery of planned work. Right inside VersionOne, you can see what code is changing and why.


What do you mean by no installation?

Since CommitStream is a hosted service native to VersionOne, the administrative burden to setup and maintain integrations is eliminated. We do all of the work on the back end and you get all the goodies immediately. There are no independent connections to version control systems that have to be loaded on a server and maintained.

What now and what’s next?

Visit the CommitStream page in Communities to find out more about the feature and how it works. In the initial release, CommitStream data will be visible within workitem detail views; later releases will include a dedicated TeamRoomTM panel as well as expanded functionality.

You are our most important source of input! Let us know what version control systems you would like to see support for as well as feature suggestions at IdeaSpace.

Posted in Admin, Platform, Point Releases, Product & Release Planning | Leave a comment

Dude, Who Stole My Epic?

When you cracked the lid on the Spring 2015 release of VersionOne, you may have noticed that the Epic asset has gone missing. Well, the asset itself isn’t actually missing – but what exactly did happen to it, and why? And what’s all this “Portfolio Item” business?

A Little Bit of Background
The term “Epic” was embraced several years ago by the agile community to simply describe a “big story” – one that is too big to complete in an iteration. As the leader in Agile ALM software, VersionOne adopted that same definition.

Over the ensuing years, the community has experimented, inspected, and adapted techniques for scaling agile. In doing so, it has learned to tackle things that not only are bigger than stories, but also larger than those “big stories”.

So the concept of “big stories” expanded to “really big stories, that can be split into big stories, which can then be split into stories.” Some have taken that even further, and use epics to include “really really big stories, that can be broken down into really big stories, that can be…” Well, you get the picture.

What We Noticed
As our customers adopted the flexible use of the epic, VersionOne’s capabilities evolved with you. We enabled you to designate epics of different types, size them, associate them with their own kanbans, view their progress on a timeline, and so on – all while maintaining cohesion within an epic hierarchy.

Still, in practice, we observed a couple of things:

  1. Different organizations have different levels of decomposition/aggregation above the level of the user story (some have a couple, others have three or more).
  2. Different organizations use different terminology for those various levels of decomposition.

It is also true that organizations often have their own definitions for the term “epic,” or don’t use the term at all. Mix in the fact that some widely-adopted frameworks have assigned very specific definitions to the term “epic,” and it is no wonder that referring to a base asset as an “epic” got to be confusing.

How We’ve Responded
Enterprise agile practices have evolved significantly, especially over the past two-three years. The concept of the agile portfolio has become broadly accepted as a legitimate means of organization in enterprise-wide agile software delivery. Along with this, it is recognized that a flexible means of connecting business strategy to execution and delivery is needed.

Although this flexibility has existed with our Epic asset for quite some time, we decided that continuing to call it an “epic” would not be consistent with how agile is evolving. That’s why we’ve changed the name of the Epic Tree structure to the Portfolio Tree, and an individual item in that tree to Portfolio Item. We believe that this better characterizes what that asset signifies: a large item of some type and some scale, within the scope of a portfolio, which represents something larger than a single team’s user story.


Portfolio Item also conveys a more appropriate level of abstraction. You will no longer have to deal with the awkwardness of saying “Epic of type Epic” and “Epic of type Feature,” etc. That was like saying “Apple of type Apple” and “Apple of type Banana.”

Through the Portfolio Item’s Type attribute, you can configure VersionOne to have Portfolio Items of any types that match the way you systematically break down your initiatives. For example, you can have a Portfolio Item of Type ‘Epic’, Portfolio Item of Type ‘Feature’, Portfolio Item of Type ‘Sub-feature’ – whatever is appropriate. This is more like saying “Fruit of Type Apple” and “Fruit of Type Banana.”

We believe that this adaptation, together with the improved Portfolio navigation, Strategic Themes, and enhanced visual differentiation of Portfolio Item types, gives you a more flexible, less confusing way to describe and visualize how your organization’s investment strategy is being realized.

Let us know what you think!

Note: We acknowledge that, for some organizations, the old terminology worked just fine and there can be a strong desire to stay with that vocabulary. We hope you’ll give consideration to the new terms, but if your organization really wants to revert to the old terminology, there is a simple way of doing so: Just have your system administrator make the terminology override in the System Configuration section of Administration.

Posted in Release Announcements, Uncategorized | Leave a comment

Comprehensive Portfolio Management with VersionOne and CA PPM

The number of organizations that are adopting agile methodologies is increasing each year.  The State of Agile Survey, published annually by VersionOne, indicated that in 2013 the percentage of organizations practicing agile was 88%, an almost 10% increase over the 2011 report.  Yet, the project portfolios of most organizations are comprised of traditional, agile, and hybrid methodologies.  This mix of project management methodologies presents portfolio managers and executives with some unique challenges.

First, it can be difficult to get a true picture of the health of a portfolio’s component projects.  This can lead to misinformed decisions around investment, portfolio balance and optimization. It can also lead to an inability to quickly change direction (pivot) based on newly emerging market conditions—one of the primary reasons why organizations adopt agility in the first place.  Further, it requires project teams to use multiple applications to perform their jobs and track their work; this is wasteful and can be a contributing factor to team member disengagement.

A Better Way to Align Portfolio Strategy with Tactical Execution

On October 9, 2014 VersionOne and CA Technologies announced a strategic partnership to provide native integration between CA PPM and VersionOne.  The integration will provide transparency, visibility and cohesive reporting of both traditional and agile software development projects to help organizations better align strategy implementation with tactical execution.

The native PPM integration couples the power of CA PPM portfolio planning and resource management capabilities with the strength of the VersionOne® agile platform, designed and built specifically to support agile software development.  Customers will no longer be required to install a special connector between VersionOne and CA PPM to enable communication.  The integration was developed jointly, runs within CA PPM, and is included in CA PPM 14.1.  Let’s examine the key features of the integration and demonstrate how it can help your organization plan, manage and track both traditional and agile software projects from concept to completion in a single console.

CA PPM Projects to Strategic Initiatives in VersionOne

Once an initiative is approved for inclusion in the portfolio, a project is created in CA PPM.  After the project is created, navigate to the “Project Summary” page under the project properties in CA PPM.  There is a selection checkbox titled, “Link to VersionOne,” which will need to be selected.  This will trigger CA PPM to create an initiative-level Epic in VersionOne and to retrieve task and timesheet data from VersionOne for the CA PPM project (refer to the figure below).

Fig 1 - Project Creation

In this example, an Epic asset titled, “Web Based Trading” is created in the top-level of the VersionOne Project Tree.  Although the Epic is created in the top-level folder, it can be moved to any location within VersionOne.  The link between CA PPM and VersionOne will still be maintained.  The figure below shows the Epic that was created within VersionOne.

Fig 2 - V1 Initiative

The agile team(s) responsible for project delivery are now free to decompose the Epic into Child Epics and/or Child Backlog Items (User Stories).  Expanding the Web Based Trading Epic reveals that it has been decomposed into two Child Epics and eight Child Backlog Items.

Fig 3 - Epic Decomposition

The initiative-level Epic Child Items in VersionOne are synchronized with CA PPM.  As Child Backlog Items and Child Epics are created within VersionOne, their Planned Start and Planned Finish dates flow back into CA PPM so they can be used to drive portfolio-level decisions.

Fig 4 - CA PPM Status Reflection

Unified Timesheet Entry

Another big advantage of the CA PPM and VersionOne integration is that it allows timesheet data in CA PPM to be populated based on effort recorded by each team member in VersionOne.  This alleviates the waste associated with requiring each team member to record time in both CA PPM and VersionOne.  The figure below shows the how CA PPM timesheets are updated simply by team members recording time spent on completing work items in VersionOne.

Fig 5 - V1 Timesheet Entry

In this example, on November 5th, Danny Developer entered four hours worked on the backlog item: “A user would like to make trades in multiple currencies.” The figure below shows that the four hours entered by Danny in VersionOne have been added to his timesheet in CA PPM.

Fig 6 - CA PPM Timesheet Entry

By leveraging the power of CA PPM resource and portfolio management with the easy-to-use and scale agile project management capabilities of VersionOne, organizations are now able to more easily plan and manage their portfolios regardless of the agile project management methodology being used on individual projects.  This simplifies the complexities of portfolio management, enabling the organization to make quick decisions – in turn, they can outperform competitors and increase stakeholder/customer satisfaction.

For more information, visit

Posted in Product Tips & Tricks, Program Management, Program Manager, Project Manager, Uncategorized | Leave a comment

Go Above and Beyond Post-its and Notecards: 5 Tricks (or Treats?)

halloweenVersionOne lets you go above and beyond manual post-its and notecards. Here are 5 tricks in VersionOne (or maybe they are really “treats”?) that you can use to quickly enter time tracking, assess the health of your sprint, and evaluate estimation accuracy:

1. Detail Estimate is the original estimate populated on sprint planning day. It is used on sprint planning day to determine total number of hours committed to by a team and compared to team capacity to see if the plan is realistic or needs adjustments. It is also used to evaluate estimation accuracy by comparing to the total effort completed.

Detail Estimate compared to Capacity and Total Done

Detail Estimate compared to Capacity and Total Done

2. Effort is the actual number of hours of work completed towards a task. It is used to assess total number of hours worked by a team in a given sprint to assess the teams pace (hopefully a pace that is reasonable to sustain). It is also used to evaluate estimation accuracy by comparing to the original Detail Estimate.

3. To Do is updated daily to reflect estimate of hours remaining to do. It is used to generate the burndown chart which is a quick visual to see if the team is tracking according to the ideal burndown rate and will complete the sprint as planned, early or if the sprint is at risk. It is also used to determine which tasks split to a new backlog item or stay with the original (0 To Do = original, >0 To Do = new backlog item).

Updating Effort and To Do hours

Updating Effort and To Do hours

Daily remaining hours to do compared to the ideal line.

Remaining hours to do compared to the ideal line.

4. Member Actuals Report shows total effort tracked by Project by member by day, week or month. This report is used to see who needs to enter time for which date.

Danny forgot to track effort.

Danny forgot to track effort.

5. Effort (w/ Date & Member) field allows an individual to track effort for a task and pick the appropriate date and owner. This field is useful when added to a grid for individuals who forgot to track effort on a daily basis and need to go back and enter time for days in the past. Note, in order to track effort toward a task, the backlog item needs to be open.

Danny entering effort for previous days.

Danny entering effort for previous days.

Posted in Developer, Product Tips & Tricks, Project Manager, QA Tester, ScrumMaster, Sprint Planning & Tracking | 1 Comment

When Waterfall and Agile Collide: CA PPM Integration Simplifies Scaling

Today with CA, we announced an exciting new native integration solution between CA PPM and VersionOne that enables tracking of agile and waterfall development projects in a single console. This solution integrates Clarity PPM and VersionOne agile project management to simplify scaling agile initiatives by providing visibility across all development initiatives.

This is important because as agile adoption continues to grow, there has been a natural tension between waterfall and agile initiatives — This solution allows the entire development organization and the business to work together, rather than be at odds with one another.

A trend toward agile

VersionOne’s State of Agile Survey shows a steady upward trend for organizations to practice agile. In 2013, 88% of organizations said they were practicing agile somewhere in their organization, up from 83% in 2012 and 80% in 2011. As this trend continues, so does tension – especially in larger organizations. For some of the 88% where agile exists, it has become the predominant view.

These organizations are working toward scaling agile — not just across the software development teams, but into the business itself. In many cases, agile exists but it is still the exception, not the rule. The PMO members who are trying to select, manage, and optimize project resource investments are facing new challenges synching with the agile teams responsible for delivering high-quality, working software.

From the perspective of the PMO, agile presents two big concerns: lack of up-front planning and loss of management control. Indeed, these concerns are reflected in the 2013 State of Agile Survey as the top-two concerns about adopting agile in general. From the agile perspective, a lack of up-front planning is a good thing. In PMBOK terms, agile relies on progressive elaboration to avoid the overhead involved in adjusting big plans overloaded with too much detail. As for management control, agile promotes the idea that embracing change should give management more control, not less. According to the 2013 State of Agile Survey, 86% of respondents realized improved project visibility as a result of adopting agile.

So why the gap between perception and reality?

It’s a matter of perspective. The PMO concerns are not specific to agile, nor even to a specific team’s adoption of agile. Any PMO experienced with many projects has seen the lack of up-front planning and management control as common causes for project failure. Seasoned PMOs know project success doesn’t come from adopting an ideal process, but is rooted in:

  • Strong project leadership,
  • A clear project vision, and
  • A habit of good communication

What agile teams need to learn is how to demonstrate these characteristics in the way the PMO understands.

This is one reason the Agile Manifesto values emphasize “Individuals and interactions over processes and tools.” Unfortunately, all too many PMOs and project teams are embroiled in the struggle over which tools to use for expressing the project vision or for project communication.

The new integration between CA PPM and VersionOne helps get PMOs and agile teams over the tool debate and into constructive conversation. The solution helps the PMO see a high-level plan coming from an agile team. It also helps an agile team turn their tracking data into timesheet data. These simple, loosely coupled data flows can provide your PMO with sufficient data to make program and portfolio decisions, leaving your agile teams with more time to focus on their work. Taking the tools problem off the table is just the first step in fostering more meaningful collaboration between these waterfall and agile groups.

What about you? Have you seen any tension between these two groups where you’ve worked (or perhaps coached)? What was the impact, and how was it addressed?

Posted in Collaboration, Platform, Product Owner, Program Management, Program Manager, Project Manager, Reporting & Analytics, ScrumMaster, Stakeholder | Leave a comment

Point Release: Updates to Summer 2014 Release

The first official day of fall, the Autumnal Equinox, is now behind us.  From here on out, the temperature begins to drop and the days start to get shorter.  It’s the perfect time for getting outdoors, sitting around the campfire, roasting marshmallows and maybe even watching the game on your new iPhone 6+ (because you can).

But as you venture outdoors and seek to stay warm by the fire, be sure to take heed of Smokey the Bear’s campfire safety tips.  They will keep you safe and from burning things up that shouldn’t be! “Only You Can Prevent Wildfires!”

Speaking of safe burning, last Friday’s point release brings you the SAFe 3.0 Epic Burn-up Chart.  It will keep you safe from losing visibility on work and it’s meant to burn-up.  Happy charting!


Posted in Point Releases, Reporting & Analytics | Leave a comment

Inside Our Dev Team: The Birth Story of Estimably for Agile Estimation

We seem to reach consensus much faster…

Summer_14_Release_main_imageIn case you missed our Summer 2014 release announcement, Estimably™ is a free, poker-style agile estimation tool (game) within VersionOne TeamRoom™ that allows a team to easily participate in story estimation exercises no matter where they work. One of VersionOne’s development teams was an early use case, and discovered first-hand the value of a good estimation tool.

The team is called openAgile, and is VersionOne’s most distributed team. Led by Josh Gough, openAgile has people in Midtown Atlanta, in the hour-north-of-Atlanta suburb, Alpharetta, in the 12-hour-flight-south-of-Atlanta city of Paraná Argentina, and occasionally at home; yet, the team still finds ways to pair program and to be available to each other for helping out and answering questions.

I’ve spoken with openAgile team members who say the following collaboration tools are part of the formula for success with distributed agile teams:

  • VersionOne (of course)
  • GoToMeeting
  • GitHub
  • HipChat
  • Google Docs
  • Email
  • Skype

Today I’ll focus on Estimably and give you the story from inside our dev team on how this tool was created, how it has helped our teams, and how it can help yours reach better consensus, faster – particularly with distributed teams – during story estimation.

Before Estimably, the openAgile team was trying to put estimate values directly onto stories in VersionOne while discussing it in a GoToMeeting. In the words of Amitai Romanelli, the team’s software-engineer-in-test, “We would discuss items and throw out ideas, after which the product owner would take the comments and suggest a number and seek agreement.” Josh characterized the process by saying, “One or two people closest to an item spoke up and basically dominated the estimate. The loudest people in the room had the most influence over the outcome. It was a problem because we focused on who, rather than what and how.”

Sometimes the loudest people in the room were those who were really involved on an item. Sometimes the loudest people in the room were those who knew the most about the technology. And sometimes the loudest people in the room were hosting the meeting. Even if the bias varied, the inconsistency in the process generally led to a feeling of disinterest and frustration.

Laureano Remedi, a developer on the team, expressed that, “Estimation was less participatory since only a few people who really knew the work were talking about the estimates. Conversation was focused and centered among them.” Many people on the team were feeling their participation didn’t matter – or, at most, that participation was difficult. More objectively, the team was taking an hour to get through a small set of stories without building solid, shared understanding.

They were already dealing with day-by-day context switching across multiple products. Even with uncompleted stories in a sprint, people were idle without a clear idea of what to do next. The openAgile team had started to do weekly backlog grooming sessions. As the product owner, I brought Estimably to the team to try out. Nominally, the team developing it was looking for feedback on what they were building. One of the developers, Acey Bunch, explained, “We tried it because we’re geeks. Plus, I think we sensed the need to find a better way to estimate.” Another developer on the team, Matias Heffel, described Estimably as, “a cool and very helpful tool that I could recommend to distributed teams, like ours. Without saying a word, you assert opinion with a simple, numeric vote. Even that simple vote can lead to a fruitful discussion.”estimably quote

Developer Mariano Kunzi described the current agile estimation process: “The moderator picks a story and leaves it open so everybody can read it. Most of the time, it comes with a context explanation so everybody can understand what is about to be estimated. Questions are allowed, too. After that, the story is put in Estimably so each individual can vote. Once that is done, the votes are shown. When there is not consensus, people in the upper and lower extremes explain why they voted that way. When explanations are done, the votes are cast once more. If consensus is still not achieved, the moderator makes or influences an outcome.”

Valentin Plechuc, another team member, described the result as, “a more smooth process with focus on what we are looking for, in this case the estimate for just one story. Overall, story estimation is more organized, more dynamic, more participatory, and with less time wasted.” Mariano added, “The new process forces me to participate and pay attention. With Estimably, you take an active role instead of a passive one (that’s a good thing!). I also think everybody gets to state their opinions, even if it is just by voting.”

“We seem to reach consensus much faster, and everybody seems to agree with the final decision,” Acey added. “We actually accomplish what we set out to do, and our story estimates are much more reflective of what the team thinks as a whole.”

“The product owner still has a lot of influence. This is not a bad thing,” Josh said. “As the product owners refine backlog items into smaller, testable units ahead of time, they set their teams up for success and for smaller estimates. This has resulted in more cohesive workitems that have better team understanding and consensus. Overall, we feel informed, up to date, and prepared.”

Check out Estimably and tell me what you think in the comments below. If you think Estimably is something you might want to try, learn more here or make a request.

Posted in Collaboration, Customer Stories, Developer, Inside VersionOne, Product Owner, Product Tips & Tricks, Sprint Planning & Tracking | Leave a comment