How to determine an items complexity | Thinking Agile

Key Takeaways

hi there everyone and welcome to thinking agile a place where we take real world problems when trying to implement agile within the working environment we will then submit those to our professional scrum trainers who would then explain what methods they would suggest to use within that scenario you can submit your questions to agile adaptdev.com or you can go to our website and use our contact form we'll then try to notify you if your question has been answered [Music] we've got another interesting topic here regarding what methods can you use to determine the complexity of an item whether it's sitting in the product backlog or in the sprint backlog so complexity i mean you could have think about that at several different levels what's the complexity of the environment that you're working in the products being developed in and then yes what's the complexity of each of the items you're actually working on this we would really suggest you look at as a component within the estimation that you actually deliver on the items so an awful lot of teams only estimate the effort it will take to deliver an item in a perfect world so i've worked using the same code on the same platform for the past 40 years therefore to do it because it's going to be quite half an hour equals half or one or whatever you want to rate on that type of thing preferably in a non-hours format um but that takes me about a lot especially new teams that are you know immature in the way they're working that's what they tend to take in account of when you talk about estimating the work to be delivered really it should be when you estimate an item you should be estimating based on the effort to deliver it the complexity of the environment your the platform the environment and the social environment that that pro your the item and the products being delivered in and the uncertainty regarding that item and delivering it and this is why it's good actually sometimes in your work you know in your kind of continuous improvement and in your retrospectives or out of the office days to do some exercises that is based on not what people do every day right so as you take people a bit outside of the comfort zone and you get them to that level of uncertainty and building complexity because it's really only through understanding that you you know if a system has seven variables then you only need to change one of those variables for people to fail to understand it in the way they've always done before right so if you take a java developer that's used to working in a tomcat environment and with an oracle database with connectivity to it and all working at that a more containerized environment you're not going to use a a war file behind tomcat you're going to have to build as a binary and you're going to use database then you'll find that that developer you know that's just raised the complexity and uncertainty factor for them quite massively and it's getting the understanding of that and not all environments the same and there have gone quite radically different you can actually be in something that's very simple and again we're still only talking software here uh again we could be talking what about if you takes a software developer that's used to delivering code that goes into your cds for microsoft type of thing operating systems even if they are doing linux at the linux at the kernel level and and you know doing some very hard level code you take that down to doing assembly language to go into a chipset and that's something completely different for them so really the methods for understanding complexity is making sure that you understand that within the item the estimate of the item to be delivered right so is when you're actually doing the estimation for it that's been taken account of and then if there's something that you think really adds and an element of it complexity from the product owner's perspective then that should really be noted on there as risks and limits or other things to be taken account because i mean complexity can be crossing border boundaries uh boundaries of power and things like that as well so if you're working on a product that not only involves your organization but involves how a partner organization connects to your systems then that's that's raised the level of complexity and you should note that as part of your notes on the subjects on the product but i'm presuming i'm saying here from that point you should be the product owner who keeps notes of this it's their product and they should build that into the discussions including when it comes to the estimation so if we're going to deliver this work yes we we could deliver it and then you know in a day in a perfect world but if it requires going to another organization and getting a hold of some of their stakeholders then that day is probably unrealistic and that's the complexity of having a product that crosses two organizations that causing that time to do the effort so it's not a straightforward simple put if i put a field in your excel spreadsheet and note down the hours of complexity you think it is but you need to take a systemic view of this and sometimes you might need to build a rich picture of what is the complexity involved in and from that i would say look at systems thinking practices and then take on what i've just said there which pictures ideal ideal tool for doing this so as you understand the complexity of the product that's actually been created thank you