Surface Aha! and TFS Sprint work

[Blackbaud-TripOtt]

I have some ideas around a new way to capture and store information for sprint teams using Stache. Who could I talk to about technical feasibility? The basic idea is this: Create a Stache template that pulls specific fields from TFS and Aha! records to generate a historical document of work done. This might be the Aha! “Problem Statement”, the Aha! “Notes”, the TFS User Story “Description”, for example.

Surfacing developer work history that combines the roadmap with the sprint work makes sense as info in both systems is buried.

Research Questions:

• Do all dev teams use the same version of TFS?
• Are the data structures consistent across various products in Aha! ? No, we have dev teams on different work management systems. Aha! has the advantage of being the one system all product managers use (they were smart to merge into one system).

We have a known issue of reliance upon tribal knowledge, we see the value of maintaining historical information for certain things, and we want to find a way to do this as efficiently as possible without the traditional burden of excess process or writing 50 page documents. What I have seen in studying my teams through the discovery process is that we have our hands on this information (in rough form) as various times throughout the process, but then we typically throw it away. When it comes to specific projects, we typically want to know things like “why did we do this?”, “what problem were we trying to solve?”, “why did we make this decision?”, “what didn’t we do?”, etc. These things may end up as notes in TFS user stories, in One Notes, or somewhere similar. We care about this information, and we do record it somewhere.

What I want us to do is to be intentional about record specific pieces of information in specific places, and then pull from those places to build a html page this is the one stop for knowledge about a project. If that page could show “What is the feature, how does it work”, “What is the benefit to the customer, and which customers”, and any special decisions around the work, this is a great starter. You will always have things like design docs or technical dev docs that get created from research from the discovery process – but those usually get linked to TFS items or Aha! anyway. If we standardized where those links go, we could easily pull those links into the Stache page too.

So, what you have is a small change in process (take the info you normally gather, but place it in specific places, and written professionally) with some kind of unknown process, manual or automated, that could pull all this together for a stache page.

Risks:
· Garbage in, garbage out – people don’t or won’t curate the content of the fields.
· People won’t see the value in this until it’s shown / proven to them

Rewards:
· Very efficient process, no need to recompile information (already in your possession) into lengthy word docs
· Anyone can do it, doesn’t require a BSA or UX – those people typically expected to write these types of docs. BSA and UX people do not live on every team, and it is unlikely to ever be the case.