Revisiting Story Mapping with scenar.io
Steven Talcott Smith
Bitcoiner. Miner. Sound money advocate. We are living history.
Back in 2012, we created scenar.io, an advanced tool for collaborative story mapping. Story mapping is an agile software design technique which helps build a complete high-level picture of contemplated software functionality. The aim is to build the right functionality in the right order. The method involves a wall with story cards arranged in rows and columns under activity headings. Story cards are arranged according to sequence, choices and priority and are grouped into releases. The technique assists with creating a backlog and performing release planning.
Our tool, Scenar.io, implements a shared virtual "wall" with index cards. It was meant to facilitate real-time remote collaboration around the software design process. When integrated with Pivotal Tracker, it speeds the process of creating a Tracker backlog.
While designing our new product, AppExpress.io, I have come to need something like Scenar.io again. The project is big and complex. It is difficult to see the big picture from backlogs in Tracker itself or even from the dashboard on in-sight.io. It is time to revisit and revive Scenar.io.
Scenar.io was the best kind of experimental application. In many ways, it was ahead of its time.
More than three years ago, it allowed us to explore the following technical directions then in vogue or just emerging:
- Single page applications with "heavy" Javascript (SPA)
- Backbone.js and CoffeeScript
- Real time collaboration using Pusher messaging
- Document oriented storage (Mongo & NOSQL)
- Skeuomorphic design (now out of fashion but it fits this type of innovative application well)
- CSS3 animation, including 3D effects
- Design for full use of large format screens 27" and larger
- Touch interaction for web applications on tablets
Normally, I advise clients and project architects to try only 1 or 2 new major techniques or technologies in any given project. Any more adds significantly to technical and schedule risk.
However, new technologies and techniques are Fun! We want to keep our skills on the cutting edge. Occasionally, for an experimental project, it is appropriate to break rules. For Scenar.io, we definitely broke this rule. And it was Fun! The goal was to see what would be possible, to learn as much as we could, and to make something really cool that demonstrated our capabilities. We sure did.
So what happened to, Scenar.io, why haven't we been talking about it?
After our soft launch, we became really busy with client work, my wife gave birth to our second child, we designed and built a new larger office for ?LOGICA and moved in, and then ... I spent 6 months in San Francisco. Somehow Scenar.io was almost forgotten.
Bugs cropped up that were hard to fix. With the SPA architecture, we found ourselves drowning in Coffeescript/Javascript unable to use familiar tools and techniques. The features I wanted to add were ambitious and I felt that we needed to go back to the drawing board to get a cleaner foundation. I felt it really should be easier to work on than it was. The level of investment required seemed way out of proportion to the expected potential benefit to our business. The market for this application is tiny and it would not likely generate substantial revenue on its own. It seemed better to operate it as a marketing asset which only justifies a limited investment. The other thing I felt strongly was that any innovative and valuable techniques we came up with, should not be implemented in a single application, but should be done in a way that we could leverage them over and over for other client or internal projects. It is such a tragic waste to have your best ideas locked up in an application that is going no where. This concern led directly to my conception of AppExpress last year. In 2013, we moved the Scenar.io production server, two of the staff who worked on it moved on over the next year, things broke and then nobody had time to fix it. This is how it came to be that Scenar.io lay dormant for a couple years. In the back of my mind, I felt guilty for abandoning this treasure. I was really proud of it and it looked great.
Fortunately, with some recent new additions to our team, we now have the resources to revive Scenar.io. Thanks to the efforts of Earle Bunao and Janice Concepcion, two of our recent college grads who joined us on July 1, Scenar.io is alive again running on our AppExpress platform!
All the things I wanted to do with Scenar.io, all the plans and all the problems are coming back to me. Only now, we have AppExpress too and I am wary of creating more software than I can really handle. So I am carefully thinking about how to revamp it - leveraging our work on AppExpress and in such a way that it will complement and enhance our offering.
Functional changes I want to implement include:
- Better support for Activities as they correspond to Epics in Tracker
- Improved importing from Tracker to make organizing a large existing project easier
- Showing labels on cards
- Color coding to distinguish icebox items from backlog items
- Cards flip over to contain more description and history information
- Support for Personas
- Undo/Redo using a Command Patttern
- Release Planning
From a technical point of view I want to:
- Replace Mongo with normal Postgres SQL
- Replace Pusher with ActionCable from Rails 5.
- Use AppExpress's Admin UX for back-end admin
- Remove most of the client side Javascript for a much lighter-weight client
- Convert back to a more conventional mutli-page app that will be easier to develop and maintain.
- Integrate with AppExpress for project metadata
This is many months of work. But its exciting.
We are planning to move to 4K 40" (UHD) workstation monitors over the next year and this format allows for truly new possibilities. Scenar.io was designed for "Big Glass" screens. I really envisioned using this tool in a conference room setting with a remote collaborator or two on conference call. Now with the advent of UHD monitors, I think it will really sing.
We are keeping it open and free for now, for experimental use. Of course, if you need a tool like this to get the big picture and set up a large project for success, please contact me directly and I can arrange a guided session.
Experienced Technical Architect and Leader
9 年This has a lot of potential, since you're primarily a Ruby shop it would be great if you could hook into Cucumber or something similar to provide BDD functionality. In terms of a development approach what I've found to be the most future proof is to try to apply the idea behind proper SOA/Micro Services all the way up the stack. This means you develop the supporting back end as granular as your data allows. The first step for the UI is to build the most basic version you can, as little CSS as possible and no JavaScript at all. Focus on just using plain old HTML to build a site that provides all the functionality you need. Next build an API to support the more advanced UI now that you know all of the interactions you need. Last build the enhanced UI using JavaScript and whatever library/framework that gives you the functionality you need. When putting together the enhanced UI apply the same patterns that are common to the back end code, keep it modular, publish events from the modules/components and unit test your custom JS as much as possible.