As a Hybrid I want the ability to create user stories into clusters so that I can isolate ideas into more finite pieces.
Seeing that most are probably likely to ask what the heck I mean? A User Story by SCRUM standards is just a small two-sentence tid bit that gives one clues as to what one should develop in software vNext? The problem with this line of thinking is that it goes against the nature of human phycology in that to isolate streams of thought into abstract finite forms does not work.
Ever sat in a Story planning session and as the stories begin to flow you immediately start to cluster these in your mind into groups? You visualize them into clusters when you see them that are because we as humans are massive fans of chunking information so that we can process them in more digestive formats. Is this a problem? No, it is just a natural primitive instinct to encourage you, as an entity that has grown opposable thumbs into ensuring the thing in front of you is both learnable and adaptable to suit what happens next.
Today, if you were to look around on the inter-web you would see a bunch of SCRUM friendly software and most of them try their best - and fail - to re-create the experience of User Story capturing. The approach they often take is to create a rounded rectangle and display them onto the user's screen as:
"this is a card and therefore it's like the one you have in your cubicle in paper form. Please use this the same way in which you would that..”
Signed Software Designer.
Recently I learnt a very important snack of UX goldenness and that is we do not use software, we work with it. Software should reflect who I am and what is contextual relevant or albeit synchronized to suite my needs vs. having to ask me to adapt to its needs. Handing someone a virtual card on screen does not offer anything of value, all it does is remind me the constraints put forward - I need to cram an idea in under two sentences in abstract form so that I can break it down further into sub-forms in order to generate software feature(s).
The Flash of Genius.
I sat down today to tackle what I call the "Opening Act" in my UX magic show for an upcoming application I am making in WPF debut titled: IWANT - Weaponizing Agile. As I sat staring the blank canvas, I began to panic a little, as I did not want to just re-create a grid of cards and declare victor to do that is to admit I have not thought about who the end user is. Instead, I went for a walk and asked myself a simple question - Why does it have to be card and what else could it be? The more I thought about the form of media given to every SCRUM disciple out there the more I started to question its sanity - more to the point, who the freaking hell said a card was the best solution to this problem? A group of people who conjured up this religion we actively calls SCRUM today?
The SCRUM founding fathers if you will have some brilliance, but I'm not sure user experience or human phycology was at the forefront of their minds when producing this thing we call User Story management via card sorting. I would however put forward the theory that they were thinking of ways to force we humans into the existence of tearing down our natural instincts to cluster / chunk information in forms that are more isolated / streamlined.
Armed with this moment of brilliance, I sat down and began grinding pixels. I began to think about the problem in the fashion of idea clouds, just like as if we were about to read these stories in comic book form. Yes, comic book form - as name any child today that doesn't find reading more enjoyable in such format and I put it to you that we adults need to recapture our lost youth as much as we can.
Like all good experimenters, I need to assign some objectives to this newfound awareness. They are along these lines:
- I want the ability to visualize clusters of user stories in ways that respect my primitive instincts but at the same time respect the existence of SCRUM.
- I want the ability engage the experience with a sense of depth that is not flat, lifeless and typical response to visual grid ways.
- I want the ability to get in and get out when I need to resurrect a User Story of a specific type.
- I want the ability to just create in a fast responsive manner and I want the said creation to have dependency links throughout that are of contextual relevance.
Armed with this tall order, I bring you thine creation.
Story Clusters. A Story cluster is a group of user stories that fall under a theme / category. The idea is to allow teams to partition their ideas into taxonomy of their choosing but more so to ensure they can feed the idea threads around a particular concept - Security? Customer Management? File Storage etc as but examples of "theming".
User Story vs System Story. They are one in the same the difference however is to give developers or engineering minded people a free pass in terms of allocating some ideas to either a person(a) or a technical agent of their choosing. An example of this is
"As a User I want the ability to save my blog posts so that I can share it with others!" - User Story.
"As a UI Client I want the ability to CRUD a blog post so that I can allow users to manage blog posts" - System Story.
Some SCRUM masters may have a mental seizure at the sight of this - deal with it you jackasses. The reality is when someone sits down to write a User Story majority of the time the person is trying to force themselves out of a cycle of developer eyes and into something, they are not. The purpose in my opinion of this exercise is to tease out the idea; we can break it down further later but get the idea captured!
The UI Teardown.
View Finder. It's here you will find the User Story cluster(s). The clusters are grouped into a cloud like existence and the more stories found within the cluster the larger it becomes. I choose to enlarge these to enforce dominance for one and secondly to attack the end user in a subliminal manner by encouraging those to break it down into a separate cluster if it is getting to large. This is exactly like a container of any kind, if you keep cramming it with stuff it gets bigger and eventually you start to think about the problem again but now are already looking at ways to fork its contents.
Notice also, how the clusters are blurred and have a sense of depth. This is to ensure the end user does not take what is in front of them for granted, I want them to focus and I want them to explore the data. I do not want "at a glance" viewing; I want interaction and comprehension around what is in front of them. Explore, interact and adapt.
Search Box. Given the end user for this product is someone who's stuck in the mental model of "As a blah I want.." style thinking, it's important for me to not interrupt that conscious thought. If they are looking to find a specific task, user story or note of any kind then it's here I expect them to take a leap of faith and search. Important thing to note here is I am not relying on this massive data grid or tree control to allow my users access to the data. Why not? It is important to not give them a crutch to lean on; I want them to think about what they are asking and how they ask it. Providing a DataGrid or Tree Control is encouraging them to embrace perspective memory way to much (i.e. they will next want the ability to pin that area of navigation, taking up valuable real estate simply because at the heart of it they don't want to have to collapse / scroll to that sweet spot again). Instead get them into UX Rehab, ask them to treat the software as if they were turning to a co-worker and asking "hey, where did you put that file.." - behold the power of search!
Create Only. Notice I do not give much in the way other than "Create" options at first. I do this deliberately as I want the end user to build first tear down / fix next. Find the thing you want to do other stuff to but here, all I am interested in is giving you ways to add to the web of data.
Some of you may notice I used a Skull as the icon to represent the User Story. The reason I choose that icon instead of a typical silhouette head of a human is simple - we are creating digital Shakespeare. You are telling a story, so it is fitting - that and this is the spot where good ideas may go to die.
Stats. I am a sucker for fun facts or a sense of proportion but more importantly, it is about keeping a score of what is going on. Too many times software hides data to the point where you either underestimate or overestimate the complexities of a given problem because of such things as software hiding key pieces of information. I choose to keep a cycle of statistics around Story telling within iWANT so that as users are working on the feature catalogs of tomorrow they are also getting some fun facts so that they may turn to one another with stuff like
"oh shi.. We have like 300 stories added this month..man, we are never going to get this done in time.." (Invoking maybe a rethink in customer expectations?) etc.
My concept is unproven and untested. It may very well fail or it could succeed but right now any feedback or questions around this approach is simply "I think" and not "I know". What I am confident about is that it will spark a different round of thinking in terms of how one approaches user story telling. My objectives are clear enough to outline the overall intent that is to provide a safe haven for undisciplined and disciplined thinking around what goes into software of tomorrow. SCRUM is a little too religious in tis procedures and I find at times it goes against the grain of human psychology thus forcing a practice into place that at times is unnatural.
iWANT is a solution I am to challenge this thinking but at the same time allow development teams of all sizes the ability to get the administrative overheads out of the way fast, cleanly and smoothly so that they can focus on writing code, grinding pixels and marketing their product(s).