In the requirements, We have recognized three classes of user: application developers, calculation consumers, and calculation authors. We have three interfaces: the API, the command-line interface (CLI), and the graphic user interface (GUI). The first is directly associated with application developers. The last two would be used by calculation consumers and authors.
So, simply looking at the users, interfaces, and the primary inputs and outputs, I started with:
As an application developer I would like to create a new spreadsheet.
As an application developer I would like to load a spreadsheet from a file.
As an application developer I would like to add a formula to a cell in a spreadsheet.
As an application developer I would like to retrieve a formula from a cell in a spreadsheet.
As an application developer I would like to obtain the value of a cell in a spreadsheet.
As an application developer I would like to save a spreadsheet.
As an application developer I would like to generate a value report.
As a calculation consumer I would like to see the values of all cells.
As a calculation author I would like to create a new spreadsheet via the GUI.
As a calculation author I would like to load a spreadsheet via the GUI.
As a calculation author I would like to load a spreadsheet via the CLI.
As a calculation author I would like to add a formula to a cell via the GUI.
As a calculation author I would like to view a formula in a cell via the GUI.
As a calculation author I would like to view the value of a cell via the GUI.
As a calculation author I would like to save a spreadsheet via the GUI.
As a calculation author I would like to generate a value report via the GUI.
As a calculation author I would like to generate a value report via the CLI.
In some of those stories, different users appear to want the same thing. However, in most of those cases they want these things via different interfaces. I’m inclined to leave those separate, because the GUI is lower priority and because each interface will require slightly different work to make it happen.
Ideally, user stories should be independent. There would seem to be an implicit dependence when se say things like:
As an application developer I would like to load a spreadsheet from a file.
As a calculation author I would like to load a spreadsheet via the GUI.
As a calculation author I would like to load a spreadsheet via the CLI.
Is it not implicit that the later two depend on the first? Well, not really. I can demonstrate the CLI and GUI functionality with a stub in place of the spreadsheet, so these latter stories really are about adding the necessary behavior to the interfaces to communicate with the API, not about implementing the API itself.
That’s not to say that there are no dependencies among these stories. Obviously, for example, one must be able to create a spreadsheet before one can load, add formulas to, or query the contents of a spreadsheet. But that’s OK. It’s a pretty obvious dependency and a team is unlikely to miss that and try to schedule the “add a formula” stories for implementation before the “create a spreadsheet” stories.
The story
is pretty broad. The language of expressions that has been defined is broad enough that we well might need to take it in stages.
Similarly, the story
is quite broad. According to the requirements, this necessitates evaluating not only the expression in that cell, but also the expressions in the cells on which that one depends (directly or indirectly). That’s pretty much the whole heart of the spreadsheet calculation model, and, if we want to take incremental steps towards it, we may need to split this story up.
The stories
can be complicated by the use of areas, so we might want to split these:
At some point in the process, we must add estimates to our stories, indicating how much time we think it will take to complete them.
For this project, I have a bit of an unfair advantage. I’ve written spreadsheets before, and so have a pretty good picture of what is hard and what is not. I may even be able to re-use some of the code from old projects in this one.
Name | Story | Estimate |
---|---|---|
ACreate | As an application developer I would like to create a new spreadsheet. | 1.0 |
ALoad | As an application developer I would like to load a spreadsheet from a file containing only simple assignments. | 1.0 |
ALoadArea | As an application developer I would like to load a spreadsheet from a file containing area references. | 1.0 |
AForNum | As an application developer I would like to add a numeric literal to a cell in a spreadsheet. | 1.0 |
AForStr | As an application developer I would like to add a string literal to a cell in a spreadsheet. | 1.0 |
AForOps | As an application developer I would like to add an expression with operators to a cell in a spreadsheet. | 2.0 |
AForFunct | As an application developer I would like to add an expression with function calls to a cell in a spreadsheet. | 2.0 |
ARetr | As an application developer I would like to retrieve a formula from a cell in a spreadsheet. | 1.0 |
AEvalLit | As an application developer I would like to obtain the value of a cell whose formula contains only literals. | 1.0 |
AEvalOps | As an application developer I would like to obtain the value of a cell whose formula contains only literals and operators. | 2.0 |
AEvalFunc | As an application developer I would like to obtain the value of a cell whose formula contains only literals, operators, and functions. | 1.0 |
AEvalRef | As an application developer I would like to obtain the value of a cell whose formula contains references to other single cells. | 1.0 |
AEvalArea | As an application developer I would like to obtain the value of a cell whose formula contains references to cell areas. | 1.0 |
ASave | As an application developer I would like to save a spreadsheet with one assignment per non-empty cell. | 1.0 |
ASvComp | As an application developer I would like to save a spreadsheet using AreaReferences to compress the output. | 1.5 |
AValReprt | As an application developer I would like to generate a value report. | 1.0 |
CValReprt | As a calculation consumer or author I would like to see the values of all cells. | 0.5 |
GCreate | As a calculation author I would like to create a new spreadsheet via the GUI. | 3.0 |
GLoad | As a calculation author I would like to load a spreadsheet via the GUI. | 0.5 |
CLoad | As a calculation author I would like to load a spreadsheet via the CLI. | 0.5 |
GAddFor | As a calculation author I would like to add a formula to a cell via the GUI. | 1.0 |
GViewFor | As a calculation author I would like to view a formula in a cell via the GUI. | 1.0 |
GViewVal | As a calculation author I would like to view the value of a cell via the GUI. | 1.0 |
GSave | As a calculation author I would like to save a spreadsheet via the GUI. | 0.5 |
GValReprt | As a calculation author I would like to generate a value report via the GUI. | 0.5 |
Let’s talk about why I rated some of these above and below the normal 1.0 level:
What’s the smallest set of stories that we could seek to implement in one increment period that leaves us a “working” demonstration?
I’d suggest:
That’s a total effort of only 5 units. I suspect that’s my upper limit of work for a single half-day work session.
A second increment could then focus on expanding the expression language:
A total of 5 units of effort, again.
Because we already have enough of the CLI in place to demonstrate evaluation, we should again wind up with an increment that shows working functionality.