fbpx

Having spent my whole working life in agencies, I live for efficiency. Not only in the workplace, but I’m now all about efficiency in my life too – why waste your, or your client’s time (and money)? Whether you’re working at a new start-up or a well-established FTSE 100 business, there is always room for improvement in efficiency. Oh, and yes, for those that know me – I have just written an article about VSTS and documentation (Automated Documentation. Yes, Please).

In our case here at Silicon Reef, and probably in the case of 90% of technology companies/agencies, creating functional and technical documentation is a necessity, but far from efficient. We’ve just changed that. We have made a huge step forward in not only managing our projects but using our management tools to then automate our Functional Specifications. It works like a dream and helps set us apart from our competitors. So, how do we do it?

We use VSTS to manage our requirements, development, testing, releases etc. VSTS is a powerful tool and I would suggest to any company looking to work in a more agile manner to at least give it a once over – watch this video if you’d like more information. Forget the Microsoft stigma, it’s great for start-ups too.

Here is what we do:

GATHER THE REQUIREMENTS.

We use VSTS to manage our requirements for a project. Using various techniques to actually obtain the requirements (post-it sessions, user interviews etc), we then manage all of these through the VSTS Backlog. We follow a common structure for our requirements and use three main Work Items in VSTS, with a couple of subtle differences to fit our Reef mould:

Epics; A related group of stories that are too large to define in one story

Stories; A description of a requirement and a reason for the requirement from an end user perspective

Features; The required technical feature to answer and solve the user story

ORGANISE THE BACKLOG.

Once we have all our requirements (at least for the release in question), we then organise them making use of the Related Work function in VSTS. This enables us to group all our work into a logical order, which helps us when we then want to export our Functional Specification. Epics become parents, Stories become children, and Features become children of their children, and so on.

CREATE THE REQUIRED DETAIL.

Once we have the backlog completed, it’s time for the nitty gritty detail. Each of our Work Items now requires the detail to be populated. This is all the detail that a developer(s) would require to turn a functional requirement into a technical solution. We use a combination of text, screen views and, where required, prototypes to help identify our requirements and their functional solutions. This gives our developers all they need to then build out the Tasks in VSTS to build the technical solution for the requirement.

We also use the Wiki area of the VSTS Project to write our project overview. This acts as the introduction to the project for our documentation and contains the business case and some background information to help contextualise the project itself.

SETUP THE FUNCTIONAL SPECIFICATION QUERY.

Once all our Work Items have the required description detail, we can run a query to return all Epics, Stories and Features and organise them using the Stack Rank feature – this gives us all our items, with their grouping in the correct Backlog order.

USE SCRYBER TO EXPORT THE FUNCTIONAL SPECIFICATION.

Once the query is setup and returning the correct results, we use an in-house product called Scryber to then generate the Functional Specification PDF. In a few minutes and magic clicks, the Functional Specification is created! More information to come in a future blog on what Scryber is and how it may be useful for your business.

This process will revolutionise our whole engagement with clients; from demand through to diagnostics. It doesn’t stop here either, we have plans to improve on this further and are already looking at:

  • Integrating all of this with our testing teams to automate testing documentation and processes even further.
  • Managing our development resources and estimation process. In the not too distant future, we’d love to be automating SoWs through VSTS, leaning on the Effort and Assigned capabilities within VSTS.
  • Further integrations of our product management to VSTS. Managing all requirements, documentation, processes, resources, testing, releases (the buzz word list is never ending) for our products and projects and where possible, automating as much of the documentation along the way.