THELAB: User Story Management – think beyond cards.

As a Hybrid I want the ability to create user stories into clusters so that I can isolate ideas into more finite pieces.

The Problem.

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.

Want proof?

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.

The Objectives.

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.

The solution.

Armed with this tall order, I bring you thine creation.

image

The Terminology

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.

image

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.

image

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!

image

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.

image

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.

The Conclusion.

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).

Related Posts:

UX Lab: Changing the way you handle CRUD workflow

I often see a lot of consistent patterns in the way applications are being built when it comes to generic create, read, update and delete (CRUD) workflows .

The usual pattern is that a screen starts off with a add/remove action followed by a very large datagrid and probably some paging. A user would then refine the datagrid’s result set, make a selection either inline on the datagrid or opens a modal via an action like double click which then presents the end user with a more detailed view of that record. This is probably so generic in the way it’s being approached that I’d probably dare say nobody’s really sat down and thought about its actual practicality – as it seems to be the unofficial standard for screen design (well the bloody apps I see day in day out anyway).

This pattern for me isn’t something I’m a fan of, maybe because it’s so common now that I simply crave for an alternative approach? I crave this alternative because I feel at times the workflow in itself seems oddly backwards?

The part that catches me out, is the overall approach taken. For instance, the end user has come to the said screen to get a detailed view of a record – maybe a summary, but doubtful. They wade around in the various amounts of turn-keys (filter settings) until they settle on a pattern of data that they can then scan (hunt/browse) for and proceed to get the modal open for a detailed view. It appears that majority of the practical usage is saved towards the end of the process pipeline? in that getting a detailed snapshot of the record seems to be an extension to the UI instead of probably being the focal point of the UI?

Armed with this style of thinking, today, I set out to try an alternative approach to the way this workflow could work. I decided to simply inverse the workflow, in that take a typical Security (add/remove users etc) workflow and try a different approach (see below).

SecurityUserScreenBkg

The idea is that when you click on “Find Users” the screen opens up to your summary view, in that since I’m logged in it reflects back my entire account profile found within the system. There are then a number of actions one can take in and around deciding on what to do next but the main key piece here for me, is well I’ve shown you the end point up front – I’ve seeded a contract with the end user around what screens will look like once they’ve found a user of their choosing.

How do I change the user from me to someone else?

image

The change button in this screen kicks off what is traditionally the first screen, in that if the end user clicks on [Change..] a modal will open over the top, presenting the end user with search criteria. The user then fires up some search results and can specify filters for their search. Once the end user has found the right user of their choosing, the modal closes and the original security profile (you) switches to the person in question.

SecurityUserScreen

Ok, I’m kind of with you, but what benefits does this give then?

I personally think it shifts the user into a more focused approach to how they handle the workflow. It’s quite easy to snap in a datagrid + tree control and hit F5/Ship. This approach in my opinion approaches the workflow differently, in that it asks the user to be specific in what they are really after. If you’re in the User Administration area of this application, then what is it you want to do? Manage users is probably the typical response here. So, let’s let them manage a User in a more focused fashion by exposing other areas of interest in a screen that’s more content specific and less cramped / buried in a floating modal.

The typical “list all users” with paging approach is quite unnecessary real estate to reserve for prime time, as well it’s merely a stepping stone to the end point. It’s almost throw away in the task process should the user want to change “John Doe” password or check when that user last logged in etc.

You could even approach the way I’ve done it differently, by simply providing a search box at the top with a label “Find User..”. Once the user types in “Scott Bar..” (auto complete) like experience fires, but instead of a pulldown it could then go off and grab all twitter feeds, flickr photos, facebook profiles, linked profiles etc and just start showing them on screen. This kind of approach is more helpful when you’re trying to figure out who that “Scott” fellow was last night, as now you’re meet with multiple forms of media to help guide your search detective skills down to a more informed end point.

The point is, it’s taking the equation of CRUD and flipping it into a more interactive experience. Why invest all this time and energy into some of the new UX platform’s out there only to use generic patterns like the original one mentioned in this post? How can you evolve this pattern further and where can the users gain in terms of data + contextual view beyond what they’ve typically been given.

It’s a new world people, try and break a few things as when you break something you in turn are rewarded with knowledge on where risk/failure can occur. Much more informative approach than “well everyone else is doing so i assume it works” policies :0

To be tested..

Related Posts: