Hey! How long is it gonna take… You know what, I'm not even gonna finish that sentence. It is a question I personally dread and sometimes even hate with the passion of a sugar’d up 8 year-old with a tantrum. Time or “relative size” (more on that later) estimations are all fun and games until a manager puts a finger in your calendar and says: “You said it would take three days”.
But let's all agree that planning and therefore harnessing the dark art of predicting the future is an important part of any project.
In this blogpost we’ll outline a new to us method of estimating. An estimation method that allows accurate estimations, even if the backlog items are not comparable. We use risk factors to quickly and methodically estimate the amount of work backlog items represent.
Reviews! Either the safety net you always wanted or the hammer that knocks your teeth out. In this blog post we will explain how to conduct a valuable, effective and pleasant requirement review.
Requirement documentation is mainly done in either Natural Language (NL) or in formal models like UML or SysML. NL offers the lowest learning curve and the most flexibility, which for many companies means: "Everyone can start writing requirements without formal training". In contrast, formal modelling languages require a considerable effort to learn and are very restrictive. But, the flexibility of NL comes with ambiguity and inconsistency. These are two major downsides that formal modeling languages aim to eliminate. Our customers often ask: "Is there something in the middle, keeping the benefits of NL, but reducing the downsides?" our answer: "Yes, a requirement syntax". But what has that children's puzzle to do with writing requirements?