The Portfolio of Matthew Almand
Menu
Case Study
TeamRooms
Providing a focused space for teams to practice Agile ceremonies.
Platform
VersionOne Agile Web Application
Problem
The largest user base in the VersionOne application is team members. The main application has so many features in so many areas that development teams cannot focus and perform team ceremonies easily. Teams must navigate, filter, and customize pages to perform daily tasks and updates.
Goals
The TeamRoom is a scoped view of a team’s backlog, stories, and tasks in a walled-off area so that teams can organize, focus and coordinate around their work and Agile ceremonies.
Team
Project Manager, Lead Developer, 8 Developers, 2 Testers, 2 Designers
Note: Our team lacked a UX Researcher so these tasks were handled by the PM and Myself
My Role
Lead UX Designer
Project Status
Released
UX Phases
User Interviews, Customer On-Site Visits, Analytics Review, Competitor Analysis, Sketching, Card Sorting, Wireframing, High-Fidelity Mocks
Section #1: Planning
Customer Interviews and On-sites
Before there was the concept of a TeamRoom we needed to understand how the developer role used our product, where their pain points were, and what tasks they needed to complete daily, weekly, and only occasionally. We gathered this info via customer calls with direct users (not company reps), and through company on-site visits.
During the on-site visits, we attended daily stand-ups and sat with developers and product teams to discuss how they did their work and where they interacted with the VersionOne product.
Through these discussions, the daily tasks became most important to them because these tasks took the most cumulative portions of their time. Tasks that the team members only completed occasionally became difficult due to their infrequent nature, which usually resulted in the user forgetting how to complete the steps needed for the task.
From the discussions, we identified the following problems developers face in their day-to-day use of the product.
Developer / Team Member Problems:
- Too many options. The application has too much functionality that causes a cognitive load each time they enter the app.
- Lack of training. Most users in this role were not trained with the tool. Therefore they either didn’t find features they needed, or misunderstood meanings and usage.
- Navigation Paralysis. These users tended to set a single view that they kept open in the browser only occasionally navigating away for a specific occasional task.
Ideation Session and the Concept of the "Room"
Upon gathering the data and setting up an ideation session with the team the idea of a room was formed. The goals of this room were:
- Block out the noise. Limit what the users see so that they are not burdened by the application.
- Avoid navigation. Prevent the need for users to have to navigate to access all the information they need.
- Show/hide data as needed. Allow the users to turn on and off pieces of information as needed to avoid too much noise within the view.
- Occasional Tasks via plugins. Provide additional occasional functions to utilize the show/hide function further.
- Build around teams. Scope and filter the data to the specific team so that they only see what matters to them.
Identify the Team Members Top Tasks
With the goals now defined for the room concept, we next looked at just what would go into the “panels” that would be shown/hidden as needed. This list was:
- Team Backlog. Need to see a team filtered list of work to pull stories from.
- Storyboard, Taskboard, or Testboard. Team members wanted to see their stories moving across the board in the various statuses to assess progress and plan.
- Closed Stories. Team Members like to see when stories/defects were completed to show how much was accomplished.
- Conversations. Users needed to talk about stories and related information and to have it available at all times.
- Metrics. Teams wanted to see their Velocity and Burndown metrics for accurate planning.
- Team Members. The teams wanted to see everyone on the team in some form.
- Recent activities. To understand what the teams were doing day to day the teams wanted a running log of recent activities.
Section #2: Concept
The TeamRoom
Now that we had the goals and tasks completed I built a prototype in Axure to convey these concepts along with how we would handle their display and layout. The above screen shows the early Axure prototype.
Initial ideas like collapsing columns and drag progression were pulled from competitive analysis of other tools with these patterns.
I presented metric data and team members along the top as fixed so that while users might toggle panels visibility these pieces of information were always available.
Due to the fixed view nature, I made the team members’ avatars clickable to filter the panels just to their data. This would later prove to be a great feature for our users.
Validation, Feedback & Repeat
With the initial prototype, we went back to our users and walked through the concept with them. After two or three rounds we had enough feedback to build a high fidelity prototype of a TeamRoom.
Section #3: High Fidelity
Final Product
I then created the mockups with the additional functions determined from the user reviews including the ability to add to the backlog directly, The ability to filter the view on a team member, the introduction of the team mascot, top panel view toggle, and the ability to toggle the panels view state directly over the panels.
Section #4: After Release
Findings & Discoveries
The TeamRoom and Room concept has been one of the most successful features of the VersionOne product even to this day. Teams love TeamRooms and are always asking for additional functionality so that they do not have to leave their rooms to perform additional tasks validating the goal of keeping the data in one view.
More recently with companies adopting SAFe as their method of Agile, it has become more prevalent that Team Leads, Scrummasters, and Product Owners, while not the largest user base, are the most frequent and heavy users of the tool. As a result, a re-thinking of Rooms is needed to evolve the tool further. We have begun this process in the first quarter of this year. However the Project Northstar is a very large undertaking so just as with the original TeamRooms it will be handled in Release waves.