What we need is a user story
There was an interesting discussion this week over on the Clarify IT Toolbox list – interesting (to me) not so much because of the technical question, but because how it brings to light user stories, or lack thereof.
The original question:
- How Can I custimize the process of "Accepting" a case. I want to have a msgbox before a case is accepted.
Some of the discussion:
- what is your customisation exactly ? what will appear in your msg box ?
- I just want to display a message Box before a case is accepted.msgbox can contain any text message like "Hello".
- Do you want the message box to appear before the accept dialogue appears?
- "Before a case moves to the default wipbin (because I am having only one wip bin), a msgbox with some text should poped up."
- You still fail to give any reason as to why you need this customisation in the first place. Sure someone could help out with the problem, but there might well be another way of doing this.
- Also, like i said before, how will you handle a DRAG AND DROP of a case from a queue to a wipbin?
- Why do you want a message box to pop up if there is only one wipbin?
- Actually my TL have given me this puzzle
What’s missing here is the user story
A few of the replies seem to be trying to flush out a user story, but it never seems to get there.
The Scrum style of story writing suggests: As <who>, I want <what> so that <why>.
If the question was in this format, I think the replies would have been a lot more helpful. For example:
As the system, I want an agent to confirm accepting a case from a queue if the primary language of the contact of the case is different than the primary language of the agent so that language communication barriers are reduced.
The story I just wrote is fictional, just meant as an example. I have no idea what the actual story is. But, if I presented a story in this format to a group, I bet I would get much better responses. At a minimum, it would have opened up a much more valuable conversation. Again, stories are placeholders for conversations.
Intercepting Clarify’s workflow process can be challenging
From a technical standpoint, I wouldn’t even begin to propose an answer to this question without better understanding the why part of the story. Especially when you’re trying to intercept Clarify’s workflow process, which can be complex. Within Clarify, I can accept a case by selecting the Accept menu item, by clicking the Accept button, by dragging a case from a queue to my wipbin, from the context menu (right-clicking the case in the console list), etc. Is the behavior different if the agent only has one wipbin as opposed to multiple wipbins? And what about other workflow objects? Does this same process apply to subcases? What about other workflow operations where I become the owner, such as the Yank/Retrieve process? Obviously, lots of questions. As the story gets flushed out, the questions may change. Regardless, a conversation must happen.
You have a responsibility
I’m sure there will be those that say "Well, he’s only the programmer. He’s been told what to do, he’s just trying to get his work done." This just brings to light one of the core issues – how is he supposed to implement something when he doesn’t really understand what its supposed to do? He obviously didn’t have a conversation with the right people. Because if he had, he would have understood the business needs and requirements. Then, he would have been able to articulate those needs to those that know Clarify well (those of us on the list), and we would have been able to offer guidance and valuable assistance on how to best implement within the Clarify system.
When the business requirements are understood, then we can then start thinking about the implementation. I’m pretty sure the business users didn’t come to the developers and say I want a message box that says "Hello" when the accept button is pressed. OK, so crazier things have happened. Even if the business users did say that – it’s part of our job as technologists to work with the business to understand their needs, even if that means helping them to articulate their own story better. We can’t shun this responsibility.
As I continue to learn about Agile techniques such as user stories, and new ideas such as Behavior Driven Development, I tend to find more and more places where these ideas make sense. I’m constantly challenged to approach problems differently and try to narrow the gap between business people and technologists.
Well, maybe if I post the same question again…
A day later, a new post:
- Can we modify the Accept case functionality? I need to show a pop up message after clicking the accept button for the case.
Apparently the first post generated too many questions – the poster just wanted someone to tell him how to solve this "puzzle". No surprise – the 2nd post hasn’t received any replies.
