Point Release Updates to Spring ’14, Winter ’14 and Fall ’13

disco-ymca-hustle

In addition to marking a new set of VersionOne point releases, June 6, 2014 is also known for the 170th anniversary of the YMCA’s founding, bringing young men in the western world new avenues for healthy minds, bodies and spirits.

Just as the YMCA founders had planned, this organization evolved into a pan-continental network of oases that liberated youthful exploration, including such notable acts as dancing on the streets of Greenwich Village. While the Village People may not have been mentioned by name in the original articles of incorporation, it’s easy to assume that the founding fathers viewed such eventual promotion as inevitable.

We recommend any dancing triggered by the fixes in this latest point release to be confined to your TeamRoom™, but feel free to dance where you must after reviewing the release notes.

There are updates for the VersionOne Spring ’14 Release, which hustles to crush a nasty Activity Stream bug, as well as the Winter ’14 and Fall ’13 Releases, which bump out a couple of fixes for ranking and API queries.

Posted in Point Releases | Leave a comment

New Point Release 14.1.3

defenestrationThis day in 1618 marked the Defenestration of Prague, whereby William Slavata and Jaroslav Martinic were literally thrown out the window after being convicted of violating the Letter of Majesty, thus beginning a Bohemian revolt and the Thirty Years’ war. While valuable, the fixes and additions for Activity Stream and Release Planning that come with today’s point release are in no way intended to incite war.

Defenestration, on the other hand, is highly encouraged for our departing colleague, Mr. Steve Paro, who has graced us with witty and timely release announcements for many a fortnight. We wish Mr. Paro continued success in life with a trajectory of the most artfully cra Continue reading

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

Spring 2014 Release: Planning the Right Amount

A new bank account holder who was surprised to find out his account was overdrawn. “I can’t be out of money,” he exclaims. “I still have checks left!

Water Glass

Drops – ©Johannes Gilger

Sometimes a development organization can forget that they, too, have their limits. Without good guidance, a group can mistakenly believe that planning should end only after all their top features get included. Much like the overdrawn banking customer, these groups realize much too late that they’ve ended up writing checks that their development organization can’t possibly cash.

It’s natural to want to get more done. We are an industry full of optimists at heart who want to deliver more and more value. That doesn’t make us bad people – it just makes us human. So how do we prevent ourselves from going too far? It takes a little forethought in identifying and establishing capacities.

In the Spring 2014 Release, VersionOne introduces capacity setting at two levels to help set limits that will guide our release planning and tell us when it’s time to stop. Teams can establish team- and release-level capacities to highlight just how much room is available when planning starts; keep track of how much room is left as they start to fill it up; and let everyone know when they get full. How about that… knowing where to stop even before you get started!

Other great additions such as the new Activity Stream, Agile Earned Value reporting and more are also included in this release. For more details, check out the release notes.

Posted in Backlog Management, Developer, Product & Release Planning, Product Owner, Program Manager, Project Manager, Release Announcements, ScrumMaster, Stakeholder | Leave a comment

The Clarity of Description

The User Story, by intent, is meant to be a short definition – an introduction to a discussion.

As a…
I can…
So that …

Simple, short and powerful. We’re all familiar with some variation of this structure and I certainly appreciate the brevity and the focus of the approach. It’s an introduction to a conversation, so let’s keep the intro light.

Here at VersionOne, we’ve been working on improving the consistency and value of the words we use when defining stories, capturing defects and defining test criteria. From “As a…, I can…, So that…” for user stories to “Given… When… Then…” for acceptance tests, the improvement effort has paid off. We’ve found our definitions to be shorter, crisper and easier to understand than in years past.

Crisp words are great, but they still are not perfect. There are times when even the best words are murky and a more substantial description significantly informs and enhances your conversations. Some cases where this arises include:

  • Focusing on a component of a larger feature, where that larger context is important
  • Conveying errors that are discovered during testing
  • Defining test cases that involve specific data setup

In these cases, robust descriptions that convey imagery and/or tabular data structures strengthen the conversations and help provide a stronger institutional memory. Recent advances in VersionOne’s rich text descriptions have provided an even better way of expressing some of the more complex test scenarios we encounter. While I was looking forward to the delivery of these capabilities because they’ve been highly requested by customers, I must admit that I am surprised at just how much I love the result.

Below is an example of an acceptance test with both tabular data and an mocked up image.

Example Test with Table and Imagery

Given, When, Then Acceptance Test

It would have taken a great many words to describe all of the scenarios covered in this one test. Instead, a table of inputs and a rough image of expected outputs removes the communication issues and allows everyone to focus on the substance of what is being conveyed.

Feedback from developers has been great on both the clarity and the expressiveness of such tests. The team has also taken to using the very same scenarios as test data, making it very easy to pinpoint what matches and what doesn’t. Such detail is not required on all tests, of course and we certainly do not put more effort into the definition than is helpful. But where there is complexity or visual importance, a table and a picture are incredibly valuable tools to clarify the murkiness.

Posted in Developer, Product & Release Planning, Product Owner, QA Tester, Sprint Planning & Tracking, Test Management | Leave a comment

New Winter ’14 (14.0.7) Point Release Available

For this weekend’s point release announcement, we’ve got a very special guest submission by the artist product manager formerly known as βθβ.

Dearly beloved, we have gathered here today
To get through this thing called owners list
Electric word list. it means forever-long and that’s a mighty long list
But I’m here to tell you there’s something else
The lookup, owners of never ending happiness
You can always see the sun, day or night

So when you call up that shrink in Beverly Hills
You know the one Dr. Everything’ll Be Alright
Instead of asking him how much of your list is left?
Ask him how much of your mind, baby
‘Cause in this list things are much harder than in the owner lookup
This lookup you’re on your owner

 prince

In short, we’ve got much Owners Lookup and Rich Text goodness, along with a bunch of defect fixes.  Check out the full release notes on the community site.

Posted in Point Releases, Release Announcements | Leave a comment

Git Some API

Many may not be aware, unless you are participating on our developers forum discussion group, that our platform team is hard at work collaborating with the community on a few different value-add capabilities. In particular VersionOne is beginning to offer a growing number of open source projects via GitHub. There are a few other samples like Python, PowerShell, and command line scripts available also.

Some of the conversations and implementations using the VersionOne API / SDK revolve around adhoc reporting. I’ll pick up on this topic again in a moment. Other conversation topics are much more technical like point-to-point integrations to other products, standalone utilities like estimation of stories, a task manager, an attachment manager, or extending presentation to non-VersionOne team members or stakeholders (although I personally categorize most of these as an extension of adhoc reporting topics). This is where the community contributes to some of what you will find on our GitHub repository.

Let’s circle back around to the adhoc reporting topics. I’ve worked with a lot of VersionOne evaluation teams and customers to solve some very specific reporting needs. In some situations we were able to leverage the API SDK to satisfy these needs. For instance, one customer had a desire to gain insight into how much value was being delivered per epic by sprints in order to optimize their release planning meetings.

VersionOne offers an epic dashboard to visualize an epic trend and you can customize the epic tree to view the data. This group wanted to pull the data into MS Excel to generate specific graphs. I assisted them with creating an API query that ultimately allowed them to do just that. Below is a screenshot of my POC against some demo data. This was created during an online workshop in about 30 minutes, with Q&A. I will follow up on a separate post with the details, but for now I hope this helps. We have since created some configuration options and additional reporting based on this POC.

Share with us how you have used the VersionOne API SDK to solve your business or technical needs. We really do value input from the community and seek to offer value based on the what your needs are. I invite you to Git some and give some…

Posted in Developer, Inside VersionOne, Platform, Product & Release Planning, Product Owner, Product Tips & Tricks, Program Manager, Project Manager, QA Tester, Reporting & Analytics, Roles, ScrumMaster | Leave a comment

When Are We Going to See VersionTwo?

Yeah.  I’ve heard that one before.

Why did we choose VersionOne as the name for our agile project management software? Think back to the times when you’ve been most satisfied with your software delivery.  For many, getting the first version of a software out the door is the most memorable.  Months of hard work have gone into a vision that has yet to be tested out in the real world.  Any number of impediments could have stopped you, but they didn’t.  You came together as a team and delivered version one.

I suppose a joke that never gets old makes it memorable, too.

Posted in Inside VersionOne | Leave a comment

Using VersionOne to Track Testing

OK, so now that we get the agile approach to capturing engineering challenges (Read part 1 and part 2 for a refresher), it’s important to see how this is done in VersionOne.  This is a pretty easy thing; let’s take a look.

First, remember the scenario we are talking about … as someone who is validating a story, you encounter something that just doesn’t look right.

Step 1 – Update the status of the Acceptance Test that I’m working on. This is an easy thing in VersionOne, on the Testboard, simply drag-n-drop the Test card to the right Status column.

Testboard Status Change

Step 2 – I may choose to capture a screenshot and some notes surrounding the scenario I was testing. To do this, I’m going to leverage one of the screen capture utilities available such as Awesome Screenshot plug-in for Chrome or Snagit. These utilities allow me to capture what is in my clipboard and upload it into a story in VersionOne.

I’m also going to add a Conversation to the original story.

Step 3 – Instead of logging a bug, I’m going to talk to the developer(s) responsible for assembling the story. If the developer was not available to talk, then I’m going to flag that story on the Story and/or Task board to show that as of right now, that story will not be able to be finished by the end of the sprint. The easiest way to do this is to Block the story with an Issue of type Engineering Challenge. To do this, from one of the boards select the drop-down action menu on the Story and select Block > With New Issue. Add the issue details and be sure to select the right Type.

Adding a Blocking Issue

Step 4 – Once I talk to the developer(s), we’ll make the determination if we just need to add another task or if it is something the developer can resolve as part of the current tasks. Here I’m showing how to add a new task to the existing story.

New Defect Task

We may bring the Product Owner into the picture and discuss if this is a missed requirement; thus, maybe it’s a new story, or it is a defect that really does need to go in the backlog. In either case, I would be creating a new item in the backlog.

Step 5 – After we’ve established what we are going to do about the engineering challenge, the team can decide together whether to remove the blocking issue now that we have a plan or wait to remove it once the failed Acceptance Test has been passed. To remove the Blocking Issue, simply click on the exclamation point icon on the board, and then click on the Remove button next to the correct Issue.

There are a couple alternatives to the above items:

On Steps 1 and 2, you could move the Status of the Acceptance Test to “Re-run” and create a new Acceptance Test that describes the failed scenario. This is a good practice to remind the team that a specific scenario failed and needs to be re-tested. It also is a good way to document the failed scenario.

With Step 3, you can choose to use the same Issue for all Engineering Challenges. I like to use the same Blocking Issue for each Team. This allows the team as well as the ScrumMaster and the Product Owner to easily keep track of the solution and/or code challenges the team is having.

Posted in Developer, Product Owner, QA Tester, Sprint Planning & Tracking, Test Management | Leave a comment

Quick! How Do I… Add Values to a List Field, Add a Custom Field or Custom List Field?

VersionOne provides a comprehensive set of default fields and values to define items in the system.  Story Types, Defect Sources, Task Components or Test Methods are a few examples.

But – what if I need to add my own list value to a list field?  Or what if I need to define a custom field visible only to my project?  Here is a quick reference guide.

1. How do I customize Status values for an item, such as Story, Defect, Tasks & Tests?

  • Log in as a System Admin
  • In Administration > List Types, select the desired asset section (e.g., Backlog, Task, Tests, etc.)
  • Add/edit the list values for the desired drop-down menu in the respective section

2. How do I add custom fields to an item, such as Story, Defect, Tasks & Tests?

  • Log in as System Admin
  • In Administration > Configuration > Custom Fields, for the desired asset – e.g., Backlog – click on Add Field
  • Add the desired custom field(s) and click on Publish Changes (lower left hand corner)

3. How do I add custom list fields to an item, such as Story, Defect, Tasks & Tests?

  • Log in as System Admin
  • In Administration > Configuration > Custom List Types, click on Add List Type, enter the name for this List Type and save
  • Click on Publish Changes
  • In Administration > List Types > Custom, add the desired values for the drop-down menu
  • In Administration > Configuration > Custom Fields, add the new drop-down menu to the desired asset(s) by clicking on the Add Field arrow and selecting Add Drop-down
  • Name the new drop-down and select the new Custom List Type from the List Type drop-down menu; save
  • Click on Publish Changes (lower left hand corner)

Now that the new list values, custom fields and/or custom list fields are in, how do I enable these for project-specific visibility?

  • Log in as System Admin
  • In Administration > Configuration > System verify if Project Workspaces is enabled; if it is, move on to the next step
    • If Project Workspaces is not enabled, the new list type value will be available for use immediately
  • In Administration > Display Fields > Project Workspace Assets select the project-level for which you wish to display the new list value, custom field or custom list field/value and click on Create Project Workspace; the system will take a few seconds to refresh and enable said Project as a Project Workspace
  • With project level selected, expand the desired asset section (i.e., Backlog Item, Defect, Task, Test, etc.); notice that there are two main columns – one for Require and one for Project Settings Display
  • Scroll to the list item that you added; if list value, click on the plus (+) sign to Show Values for the drop-down menu and select the checkbox for the new value; the system will apply the changes and show the message “Field Configuration saved successfully” after a few seconds
  • The new list value, custom field or custom list field/value value should now be available for the item at the desired project level

Keep this reference handy! :-)

Posted in Admin, Getting Started, Product Tips & Tricks, Sprint Planning & Tracking | Leave a comment

Organizing and Associating Work to an Epic

We have many teams within VersionOne using the Epic functionality heavily to organize their work.  I often get asked questions like:

“What if I decide later on that my work is tied to an existing Epic?”
“What if I decide that my Story really is part of a bigger initiative?”
“Is there an easy way for me to quickly generate and Epic from that Story?”

Luckily VersionOne takes into account these scenarios and more.  See for yourself below on the different ways we allow you to organize and associate your work to an Epic.

Posted in Backlog Management, General, Product & Release Planning, Product Owner, Product Tips & Tricks, Program Manager, Project Manager | Leave a comment