Examining the ongoing challenges of delivering high-quality, value-added ERP services in Higher Education.
Wednesday, September 26, 2012
I like telling stories. For a while I thought I might have a future in telling stories, and someday I'll write that Great American Novel, I swear... But for now I must content myself with Agile stories.
"Story" is an interesting word. For me -- perhaps for anyone who has studied or practiced creative writing -- those five letters prompt an avalanche of thoughts; now that I have tried my hand at writing user stories according to the Agile/Scrum methodology, I realize some of that training might actually come in handy in my "real" career after all.
The concept can be quite foreign, and initially I have refrained from explaining the concept to my stakeholders, anticipating that illustration by relevant example will be infinitely more effective than abstract, slightly jargon-y concepts. So yesterday I sat with one group of stakeholders and worked through a story-writing session (without ever calling it that). I listened carefully, asked "why" about a thousand times and captured exhaustive notes. In the back of my mind, I was writing the user stories as I went along and shaping my questions to fill in those critical blanks in the formula.
User stories are a lot like "ad libs" (I'm surely not the first to say so, but I haven't checked). "As a ____ I need ____ so that I can ____." The first blank is a cinch -- usually obvious from the person stating the need. The user often thinks the middle blank is the easiest. Much of the time, I think the third blank is the hardest. (And the second blank is seldom quite right once you gain clarity on that third blank!) When it comes to the "so that" question, a blank stare certainly tells me something... But it often takes some probing to get to the good answer, which is essential to breaking down a story into discrete (and more digestible) sub-stories. In some ways, I think it makes sense to walk in with a pick-list of potential so-that actions -- in all honesty there aren't that many possibilities!
Here are a few of the stories I wrote: (accepting any and all feedback)
- As AP SUPERVISOR I need to understand the gaps between key procure-to-pay dates so that I can identify potential process bottlenecks and local (dept) interventions.
- As REIMBURSEMENTS MANAGER I need to analyze employee reimbursements data by Object code (Air, Meals, Lodging) by School to facilitate conversations with departments, employees, card services provider, procurement, etc.
- As DISBURSEMENTS MANAGER I need to be able to see a list of the top employee reimbursees so that I can identify potential under-utilization of the Corporate Card, potential fraudulent activity, and/or other policy issues.
- As AP SUPERVISOR I need to analyze the gap between Invoice Date and PO Date for Payment Requests by School/Cost Center to identify areas where users are holding invoices locally so that I can reach out to School leaders.
Our (my) journey down this path is just beginning. I wrote a dozen stories today and my team will take a crack at another dozen tomorrow. The stories can be powerful in succinctly stating who, what, and why all in the span of a Tweet. But we shall see how things go when we try to go from building a backlog to planning a sprint! Next step -- story points and technical tasks!
Labels: Agile, AgileBI, Scrum
0 Comments:
<< Home