On a Monday morning, about three weeks ago, I am given the opportunity to create my first “real” app through a process known internally as the Partnership Project. Plainly put, this is a chance for an apprentice to collaborate with his or her mentor on a project that can add real business value, together interacting with another craftsman who plays the role of a demanding client. Over this and the next four blog posts I will relay my takeaways and present the successes and challenges I encounter along this journey, beginning with the initial client meeting, through three iterations of code, and finally to the interaction where I deliver the goods to the stakeholder.

The project begins with an exploratory discussion. This is a chance for me to engage with the software craftsman acting as liaison between me and the non-technical “purchaser” of the product. I learn that my client is a sales professional looking for a way to keep track of her clients and respective obligations. She wants to be able to keep track of tasks assigned to each client of hers, give each task a priority level, and organize the list of clients and tasks in a clear and concise way. From this meeting we determine that the value of this product lies in two key features: being able to have an overhead view of tasks to do, and being able to see a list of completed tasks organized by client.

With these two features in mind I work with the liaison to come up with a list of acceptance criteria. These are a set of agreed-upon features and implementations that are (ideally) unambiguous and can be committed to be completed in a given timeframe. Below is the set of criteria we agree that the software should make possible:

Features
- Create a new client
- Create a task
- Mark a task as being highest priority (only one can be highest priority)
- See client name and top task for client when looking at clients

Implementation
- Clean markup (HTML)
- Normalized CSS (Require CSS file from somewhere else)
- Deploy on local machine

I estimate that optimistically, if everything goes correctly, I could complete these features within two points of work (1 point = half a day). I estimate that realistically it will take more than a day, say, 3 points. And pessimistically, if all the things go wrong that can go wrong, it will take 5 points. With a weighted average calculation, the final estimate is brought to 4.25 points. The liaison insists that he can only pay for up to 4 points of work, so I decide not to split hairs and acquiesce by committing to the agreed upon terms. There are still a few things I need to get done this week, so I won’t start until Thursday afternoon. If worst comes to worst, I know I can (reluctantly) go into crunch time over the weekend. We decide to meet again on Monday to discuss the results of the first iteration.

In the next post, I will talk about how I tackle the first iteration. I’ll go over some of the technical details and choices regarding the language and structure of the project, and I’ll also talk about my first demo for the liaison.