Plan­ning Poker

Then on the count of three, one, two, three…. How much is it? How much did you show? This is thirteen, and David that is twenty-one? Then let's talk about it.

It is a typical, everyday conversation with the team. We use Planning Poker to estimate the complexity of the tasks. At Integral Vision, we do not use hours, but story points known to many, to determine the complexity of the functions. Developing a particular feature takes more time for a junior developer (even up to twice or three times as much) as it does for a senior developer, but that doesn't make the feature more complicated.

Estimation is fundamental to me as an account manager who has a close relationship with the customer. With this information, I can help the client decide if a particular development (such as a new list view, a sorting method in the list, or even just displaying a button on the home page) is worth it or not. It is a method to weight developments relative to each other and always work on features that are most optimal in terms of value for money.

We see each other as partners with our customers. We make decisions together, having all the relevant information. It sounds good in theory, yet I have found myself in a myriad of difficult situations about estimates, which have sometimes destroyed trust or forced us to make unpleasant compromises.

The estimate was not accurate

Of course, it's never the a problem when we overestimate. The difficulty tends to arise when we come across an element of a complex system, possibly involving a connection to a third party (e.g., CRM, bank payment). There are tasks whose complexity can either be revealed only with a lot of energy investment (i.e., a lot of time would have to be spent on estimation). In other cases, during development, there is an unexpected obstacle that we can only manage with more time and energy. In this case, an implementation may be more costly than previously estimated.

An additional function was implied by the client

There are typical topics that customers with experience on the web take for granted and implicitly include in other features. For example, it might seem trivial to send a webshop letter about the purchase. Of course, on the site, admins can view statistics about users. It is not worth mentioning that the whole application is responsive; all functions work on mobile and tablet. 

There was not enough information

The database we are trying to migrate is full of invalid data. The previous payment provider handled rounding differently than the one we switched to. It turned out that the site needs multiple languages. We discover later on that the parameter describing the size of some products is not just a number. 

Together with the client, we balance in an uncertain circumstances. It is up to both of us to decide whether we can uncover enough information in advance to make our estimate grossly accurate. I can help by asking, trying to explore as much as possible about the most important functions, the ideas. I also think about what is implicit, and I draw from my experience, I ask. And clients help me explain their product, their topic, and I understand more and more what might be relevant to an archaeologist, a roofer, or a railroad operator.

A web application is never complete. We have never gone live without having many ideas for further improvements to make the site even more convenient, even safer, even more user-friendly. All releases include compromises and simplifications. In a work environment rich in such agreements, mistrust comes at a high price. We can only achieve the right result, and cooperation is only effective if we trust each other. When our clients see that what we say is in line with the reality. The reality that can be known at the time. We ride the waves for the sake of the project together.