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

A Transition Exposition

We are often asked about updating a story status when a task or test begins its progress.  While VersionOne chooses to empower the agile team to make these adjustments as opposed to doing it automatically, we do have a feature which many users may not be aware of that can assist with this.  To those who do not know, I introduce the concept of Transitions.

Transitions can be found in the Administration -> Configuration -> Transitions tab.

Transitions Page

Transitions Page

Transitions allow for certain movement of Backlog Items, Tasks or Tests when the Quick Close or Sign Me up actions are performed.    The Transitions page allows you to set the appropriate statuses of those items.  As you can see in the sample image, upon Quick Closing a story, the status will be set to Accepted, the tasks belonging to that story will be set to Completed and the tests will be set to Passed.

Once you set them, in order to take advantage of these actions, you can choose them from the action box to the right of each row in our grids, or you can choose them from any of the board views.

Grid view showing Action Box

Grid View

Board view showing Actions

Board View

So, now that you are a master of Transitions, allow me to drop some more knowledge on you.  You may notice when opening the action box, a value for Close and the aforementioned Quick Close.  “Whoa… stop the clock… two options?!”

When a user chooses the option to Close an item they have more control over the flow of that item.  They will be presented with the choice of which status the item should go to and furthermore, if you are doing Build Run reporting, you will have the option to assign that story to a particular build.  On the other hand, when you elect to Quick Close a story, you are taking advantage of the Transitions that you have already set up.

It’s important to know that in both cases, Close and Quick Close, the action will zero out the hours in the To Do field for any tasks or tests.

Search for more information on Transitions and other spring planning/backlog management tips at our VersionOne User Community site.

Happy Agile, Everyone!

Posted in Admin, Backlog Management, Product Tips & Tricks, Sprint Planning & Tracking | Leave a comment

New Winter 14.0.6 Point Release Available

As you’re all probably aware, St. Patrick’s Day is only a few short days away.  On this day that celebrates the most commonly recognized patron saint of Ireland, it is estimated that American revelers alone will rack up a staggering $255 million bar tab.  With that much alcohol being consumed, it’s pretty safe to assume that more than a few inhibitions will be misplaced that day.  Fortunately, this St. Patrick’s day, VersionOne has got your back.  While we won’t be able to help with the aforementioned misplaced inhibitions, we will be able to help with misplaced child epics and stories.

For this weekend’s 14.0 point release, new alert has been added when an epic’s children appear to be misaligned. When an epic is dragged into a release and the epic contains children (epics and/or backlog) that are in some other release/project, the system alerts the user and provides an option to unite all of the epics’ child items in the same release into which the epic has been moved.  In addition to this, we’ve got 10 new defect and performance fixes for you as well.  We’ve also got a 13.3 point release as well.  As always, check out the release notes on the community site to get all the details.

Posted in Point Releases | Leave a comment