I generally prefer not to estimate story points or anything similar, but sometimes we have no other option - be that because of stakeholders' expectations, development team's habits, etc. So, if we have to estimate for any reason, then at least let's not put more than a little bit of effort into this activity. I'll explain why I think so using an example which I find to be a really nice metaphor... or maybe something more than just a metaphor.
My kids developed a strong interest in the Roblox games. We had to establish a time limit on the use of our home laptop. Once the limit was set and put into daily use, the kids started to invent, day by day, ways of utilizing the limit in a manner that was most efficient for them. Let me give you a sample of what they came up with during the first week:
Concurrency is hard. Even for those who have been through a university course of concurrency, the alignment of theoretical knowledge with implementations in mainstream languages is hard. I want to tell you about a couple of basic scenarios where mutli-threading may seen like a promising idea to increase a program's throughput and what constraints come very quickly into play, making it more difficult than it might initially seem. I want to do it in an approachable manner, so that anyone with only a basic experience in programming can understand and take advice.
Based on ethnographic study, the following mental characteristics of Aboriginal Australians have been discovered:
(AB1)"By trial and error" method is the dominant way of dealing with problems. Copying someone else's approach to problems (even successful) is not the first choice.
(AB2) There is no competition between people, no need to be as good as someone else in something. It's very seldom that someone wants to rule or dominate over others.
(AB3) The focus is on the present time, thinking about the future does not happen often.
(AB4) The thinking is mostly pictorial, non-verbal.
Isn't it astonishing how much these characteristics have in common with what we strive to achieve with our agile software teams?
In this post I aim at providing a solid overview of what Unit Tests are and what TDD is. It is intended for people not familiar with TDD yet and definitely not for seasoned developers. I'm not presenting any fancy or advanced methods, instead, I'm focusing on explaining TDD in a way that is easy to understand. Also, if you want to learn what TDD is about but your role is different than a developer, you are welcome to read on watch the video. It should help you understand what it is, what its benefits are, but also how much discipline it requires to be done right.
Have you also had this uncomfortable feeling that your product or sprint backlog is so different and so less tidy that the examples you read in books or articles? I have had it. For some time I even believed that there are those legendary teams and companies somewhere whose backlog is just like from a book. Fortunately, I no longer believe it. A picture is worth a thousand words, so here's an example of a difference between tidy, theoretical backlog of User Stories and a real-life backlog that we deal with on a daily basis.
I was once told a story about a software company that existed in the '90s and worked, among other things, on a GUI library that was meant to be so deeply configurable and customizable as no other GUI library in the world.
If they had a slider being built, they wanted the slider to work not just linearly from value A to B, but they wanted the developers to be able to assign a function (not necessarily linear) to the slider, so that when the user moves the slider, the resulting value comes from the function.
And the same with any other control they wanted to built. There was so much complexity involved that the company had never actually shipped the library.
This example is on the high end spectrum of making a product configurable. Let's take a look at a simplified picture of the spectrum.
