We found ourselves in an interesting spot today: tried to start estimating on stories, and quicky found ourselves going in circles. It felt like we wasted quite a bit of time getting hung up on trying to reconcile what we "should" be doing with what we instinctively knew we needed to be doing. The tricky part is that we're bound by the following constraints:

• Project is fixed budget and fixed scope
• Expecting to encounter drastic change (but it's still fixed scope...)
• UI prototype is to be used by client to engage stakeholders and stimulate feedback within their organisation
• UI prototype must provide a comprehensive representation of application features and cannot be a throw-away

Initially, our thinking was aligned with translating a user story into a potentially shippable feature which meets our definition of Done. Well, our stories certainly translated nicely to features, but we were struggling with the idea that we would end up delivering software that was no where near Done.

I think the thing that helped us shake ourselves loose was applying the YAGNI principle over and over, which really helped keep the focus on implementing only what was necessary to deliver the first iteration. By doing this we came to the realisation that we actually didn't need to go past the UI layer, thereby reducing the majority of what we perceived to be potential wasted effort and helping us remain as flexible to change as possible.

We talked it over quite a bit, but it wasn't until we actually started estimating that I began feeling confident. I think this was primarily due to the process of abstraction. It's a good reminder that if you get stuck on A, moving on to B should eventually make A more easily solvable. This tends to happen naturally through the process of abstraction. By abstracting away B, you've most likely reduced the complexity of A, sometimes so much so that the solution to A becomes suddenly all too obvious.

First we looked at using a mock repository behind the controllers to get data into our view models. Then we asked ourselves if we really even needed view models just yet. Not too surprisingly, the answer was no. Just one more thing we'd need to change later that isn't going to add much value right now. Once the penny dropped, we took a more pragmatic approach to each of the user stories and started feeling good about our estimates. No doubt we'll have to throw away a bit of duct tape at the start of our next sprint, but the pieces being held together by it should be highly reusable and simple to refactor.

Should what we deliver at the end of this sprint be considered working software? I can't bring myself to say yes. I think "working prototype" is probably more appropriate - it's a spike solution, but we're investing enough to make it a keeper.