This cookie is set by GDPR Cookie Consent plugin. These cookies ensure basic functionalities and security features of the website, anonymously. Necessary cookies are absolutely essential for the website to function properly. ![]() Scrum and XP from the Trenches – Henrik Knibergĭid you know, Clearvision provides an expert consultancy service to assist organisations in adopting agile practices and tooling? Click here to learn more about that consultancy service. Scrum – The art of getting twice the work in half the time – Jeff SutherlandĪgile Estimating and Planning – Mark Cohn This also means feedback can be gathered to validate the solution, ensuring it is in fact what the customer needs.įor further advice on estimation practices, try the following books: Large items should be broken down if possible, into smaller deliverables for greater value to the customer at a faster rate. Sometimes an easier solution that is both cheaper and faster than what the business originally asked for can be found. ‘Spikes’ are often used to research areas of complexity a lot of the time, something that’s complex isn’t really understood, so maybe the requirement itself should be challenged. If a team identifies a story as complex, it’s often a good idea to ask why, and then follow up with a way to mitigate the complexity. ![]() This is necessary sometimes, but whenever anything large or complex is required, it adds risk to the successful delivery of Sprint goals. Quite a few teams think it’s okay to commit to delivering large or complex items of work in a Sprint. If it’s a small piece of work, it needs a lower Story Point value, and if it’s big, or complex, it needs to have a higher Story Point score. Sprint planning really comes down to how much ‘work’ can be fit into the next increment. A lot of teams overthink Story Point estimation, and there are often long-running debates over size and complexity, the impact of the phase of the moon, football results, and so on.Įstimation really boils down to something quite simple - how much work is involved. Let’s say you can’t polarise estimation by using size or complexity and therefore need a mixture of both. On the other hand, a small piece of work considered complex can take a while to introduce most developers understand the damage a single change to a line of code can have, not to mention the amount of testing that can follow a small change to a shared component. So, when it comes to estimation, complexity has got to be a factor, but I don’t think size can be ignored when it comes to estimation - a large piece of work may simply take a long time to do. In fact, such works are often deemed low-risk, making them more likely to be produced at a faster rate. ![]() a piece of code to create, view, update a record, may be considered large, but this doesn’t mean that it’s complex. The original article argued that complexity has a far greater impact over size, when it comes to the amount of time a unit of work takes to complete.Ī piece of work performed several times over e.g. Discussions can differ between whether a User Story is a Terrier, a Border Collie or even a Great Dane! The blog in question was about Story Points, which are usually a measure of size teams learning how to estimate using Story Points often refer to abstract sizes such as dog breeds to help them learn.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |