Exploring to Get Specifications & Story Tests

Today was day 2 of a new sprint. We’re working on a big, complex theme. Up to now, our system allowed only one employer or “plan sponsor” account for every 401(k) retirement plan. Many companies want several plan sponsor accounts: one for their accountant who submits the payroll contributions, one for the human resources manager who enrolls employees, one for the company lawyer who reviews the legal documents, and so on. With this theme, we’re making it possible for each plan to have multiple sponsor accounts.

We created a mind map during our theme planning and it shows that this change affects many parts of our system. We identified several user stories, but felt there were still some loose ends we hadn’t yet identified. We wrote a story called “Close the gap” and wrote one big development task card with 32 hours on it. We wrote lots of testing cards, to identify the “gaps” and do lots of regression and exploratory testing.

Friday and today, I explored the system looking for those gaps. Last sprint, I had already discovered several reports that didn’t work for the additional sponsor accounts, so I went looking for more reports. I logged on as all the different user types in our system: customer support reps, plan administrators, third-party administrators, plan advisors, as well as plan sponsors and employees (participants). I found more problematic reports and UI pages, and some searches that didn’t work.

Here’s an example of what I learned. We have an “account details” page that is used by three different roles that shows information about a given 401(k) plan. It links to an “account summary” report that lists all the information about the plan. Both the details page and the summary report list the plan sponsor for that plan. Now that a plan could have more than one plan sponsor, what should show in these locations?

I went and talked to the VPs over four different departments of our small company that have a stake in this functionality, each with a different point of view. We looked at the account details page and the account summary report, and agreed that a simple approach would be best: change the label “Sponsor” on the account details page to “Account Representative”, a new concept in our system which identifies the person whose name goes on all the legal documents. In addition, we’d have a new page that lists all the sponsors for the plan, with columns for each item of information such as phone number and email, and link to that new page from the account details page. We can probably use that same page in other areas of the application. The sponsor information can be removed from the account summary report.

I discussed this idea with one of the developers, who agreed it was probably the simplest and least costly way to provide the information. Then I documented it on the wiki page for the “Close the Gaps” story, including screenshots on which I made notes about what to do. I wrote high-level test cases, and identified where we need more detailed, automated test cases (I’ll start on those when a developer starts working on the coding tasks).

The Product Owner thanked me for finding some unexpected places where this theme “poked out”, and helping to identify low-cost solutions. I enjoyed exploring some of the more obscure parts of our application, learning more about how they work and what needs to be changed, and writing specifications and test cases so that the developers will know what to code.

Here’s a snippet of the wiki page. The links bring up annotated screenshots. (Click the image so you can read it!)