Our team is designing a smart client application that behaves much like a browser. We want to provide a tabbed browsing experience for the users and we want a CTRL+N style function. That is, we want a user to be able to “pop open” a new browser and have the current window move from the old window to the new one. Great… easy enough to handle in a traditional application by changing the .MdiParent property of the current view (mdi child windows form).
So how would this work when using CAB? Trying to solve this design problem has led me to wonder, “why not just create a ‘Browser’ work item”?
This, in turn, has led me to the theory that the “Shell” concept in CAB is useless for our purposes. We can and should register our UI “plug-in” points as a browser WorkItem. Child work items for each module will then be loaded as new “Browser” WorkItems are created using the default IWorkItemTypeCatalogService.
Got through the huge stack of cards from Friday’s story workshop. Everything’s in our application (VersionOne). I found it kind of hard not to editorialize the process as I transformed these things from paper to an electronic form, but I stayed disciplined. A couple issues I noticed were duplicate stories, too-small stories (interesting, I thought we’d have more of a problem with epics), and an awful tendency to write stories in terms of comparison to the legacy software.
Any changes I did make were to steer the stories away from “too-small” or “comparison specific”. For example, we had lots of situations where we’d have three or four stories representing a CRUD scenario (e.g. “Create an Entity Type“, “Delete an Task Type“, “Modify a Task Type“). If they were simple, lookup-type items I merged them into “Manage Entity Type” stories. Another thing I did was to create a title for each story. This makes it easier for people to identify the item in a list or report.
Tomorrow we’ll spend a good chunk of the day estimating the stories, then we’ll hit the customer team with prioritization duty.
Recently our team has switched to user stories as a means of capturing requirements. Our first “story workshop” happened today and it was a real success. We wrote around 80 good stories for a new project we’re starting in a month or so. What suprised me most is that everyone (even non-technicals) latched onto it right away. I did find that I had to remind people not to express stories in terms of the software they are currently using (as we are replacing it) and, especially, to avoid expressing stories as negatives (a user cannot…). When you’re replacing a system you can just leave the negatives out.
(Mike Cohn’s User Stories Applied is good stuff. Highly recommended.)
A little background: we’ve been using a slightly modified form of Scrum for around a year in a small, six-person development shop. In the beginning we tried a 30-day sprint as recommended, but changed the length to three weeks in an attempt to get management buy-in on a control cycle. I work from my office in NYC and the rest of the developers are based in Syracuse, NY.
Our first pass at capturing requirements was a homebrew technique that used short bullet points with IETF RFC-2119 keywords. The tendency there was to express things in terms of the technical tasks required to implement a project. For one reason or another, things broke down and we slipped into the “oral tradition” of capturing and communication. Hard to pull everything of the top one’s head when asked to provide an update on project status.
When we started using Scrum, we used an excel workbook to track our backlog and sprint. Again, things were expressed in very technical terms. Great for the developers, but difficult for stakeholders to get a handle on where things are and what value we’re bringing to the table.
An attempt to use Use Cases never got off the ground (overkill for our purposes).
I’m looking to user stories for a couple of things:
- Help make our reports more meaningful to the customer team by expressing progress in terms of business value.
- As we break down user stories into the various technical tasks, ways of introducing inter-dependence between team members Up the collaboration factor and leverage the team dynamic with our developers!
- User stories are (relatively) easy to capture (and therefore keep going as a process) and leverage spoken communication.
This blog is meant to chronicle my experiences as 1) a professional developer and 2) an owner/operator of a startup ISV. These days you almost have to have a blog to be in the technology biz (see the tagline at the Obligatory Blog).
That said, I intend to keep my posts restricted to the stuff I deal with in my day job: team management, agile development, industry, and technologies of interest (.NET, tools, & whatever else).
The ‘bee log is the breadcrumb trail of my experience: a subjective measure of how often I can obsolete myself and all-around convenient place for me to dogfood my theories.
