Objective
The objective of the session is to convince the audience that visualisation in it’s many guises can be a tool that is used to help during every stage of product/feature lifecycle

Background
The techniques discussed are all derived from real life experience, more heavily realised and utilised over the last 8yrs, but some aspects have been used prior to that. The talk includes a combination of established drawing techniques (such as sequence diagrams)

Structure
The talk begins with an introduction as to why we are talking about visualisation. taking us from times when there was very little definition in terms of use case, feature, and design, quite often there was nothing documented and no discussions. through to the realisation that we’re doing things wrong and the decision to use ACs (of varying quality) etc, which is where a lot of folks are now.

We then walk through a scenario using traffic lights as our design goal. the traffic light concept is understood by many, so it’s easy to understand. There’s a comparison of ACs (not in detail) and the visual approach to demonstrate the effectiveness of representing the behaviour visually vs doing so purely via ACs

* key point - visually representing a problem gives more understanding to more folks quicker.

We then take a step back and look at the problem we are attempting to solve with these traffic lights, this is the business problem. we take a written scenario and suggest a few solutions, and then we draw out the problem.
This promotes discussion, the participants can see that working through the problem visually helps to eliminate assumptions.

* key point - diagramming isn’t only for the engineering teams, and the lack of understanding of the real business problem can lead to the implementation or a solution that doesn’t match the problem

Having explored the business problem, we then revisit our traffic light ACs, diagram and see what was really required and adjust as necessary, again with comparisons of the 2 approaches. This may sound a little out of order, but teams frequently focus on the design of a solution a not enough time discussing and understanding the problem. this revisit hopes to highlight that omission.

we then take a quick segway to look at other industries using visualisation, the purpose here is to reinforce that visualisation is beneficial and used outside of IT to great effect

We then delve into the engineering side of the feature and talk through design, sequence diagrams, etc, we pick a scenario and talk about the benefits of using this, and how the visual design is easier to follow, and of benefit to more people than just those writing the code. We see how easy it is to identify edge cases via the visual representation

* key point - visualisation enforces best practice for design

Taking the design, we then move into tasking. This is a technique that we created a number of years ago, which results in an approach to tasking that is superior to the traditional methods of just adding the tickets to jira. This approach highlights benefits such as: 
simpler prioritisation calls
opportunities for resource parallelism
identification of real mvp for a feature
more accurate tasking

* key point - more accurate, and informative approach to tasking

We then extend this tasking technique and show haw it can be used to quickly demonstrate progress. This is something we use in our projects and we use the diagrams to guide the standups and other ceremonies a client may request.

* key point - team communication. everyone can quickly tell where there project is at

Finish off with a reference to a free version of a tool we’ve put together to automate this process