Story Points: Is finding complexity complex?
On a sunny Monday morning, Adam, along with other workers headed into the manager’s office to get their tasks for the day. Adam got the task of moving the sand from location A to B.
Chris(Adam’s Manager) and Adam sat down for a quick chat and Adam mentioned that it would take about 8 hours to move the sand using his shovel, but it was a simple task, and Chris made a note on his dashboard:
Task: Moving the sand from Point A to B
Effort: High(8 hours)
Adam then picked up his shovel from the toolbox and started picking the sand from A and then dropping it at B. It took him about 8 hours to finish moving all the sand. He was tired and exhausted with all the back and forth, but knew that a drink was waiting for him when he would reach home.
Chris wanting to innovate, decided to try using a tractor the next day and shave off some of the effort.
With a bright Sun shining, Adam and the other workers walked into Chris’s room to pick up their tasks. Adam again got the task of moving the sand from point A to B. The new pile had arrived last night. As he was moving out Chris stopped him and said, “Use the tractor to move the sand it would be faster”. Adam was a bit surprised, as the tractor was a big complex machine with too many gears which he would have to learn, but he understood that with the big extension that the tractor had, he would be complete the task in no time.
As a routine, Adam and Chris sat down analyzed that the task and charted down:
Task: Moving the sand from Point A to B
And with that, Adam began his day and by noon he had completed moving the sand. And was ready for his next task. Adam went back into the office and picked up another task and completed his day on a happy note, having learnt how to use a tractor to move the sand.
Adam and Chris, both happy with the outcome and innovation done today, walked out with a smile on their faces.
If we look closely, we would see, that the task did not change, however, by making subtle changes in the approach such as by changing tools, technology or people the complexity and effort needed for the task changed drastically.
Let us drift from the story a little and assume that, the task of moving the sand using a tractor, would be assigned to someone who was well versed with using a tractor, then, the task would have been categorized as very easy(Complexity = Easy) and he might have completed the same even faster.
Applying the same in our IS world, let us try and identify the different factors that could impact the complexity and view them from the eyes of the Development Team(A simple development team includes: Product Owner, Developers, Testers & Scrum Master):
The clarity on the requirement is the most important. But that does not mean that every parameter and every button is defined. The requirement should be clear to the point that it can help initiate discussion which results in innovation. Because only in the channels of innovation can we build a better product. Lack of clarity on the requirement would increase complexity. Good clarity would help the team, identify the actual complexity would drive the best solutions.
2) Tools & Technology
There should be clarity on the tools and technology, which should be in line with the Enterprise Architecture Vision. Any discrepancies would lead to an increase in complexity. And clarity would help build a better and more robust framework for the future. This is more often referred to as Technical Complexity.
This is the most critical aspect of complexity. Different team members coming from different backgrounds, experience, knowledge would have to come together and judge the complexity as a team. A requirement could be easy for the developers as it could only be a minor configuration change, however, the same requirement could become complex for the testers, as it impacts multiple scenarios and vice versa. The team should always discuss and come up with a common approach and complexity parameter, which will act as a guide and push the team towards successfully completing complex requirements.
4) External Dependency
This is where things get very tricky. Things which are out of the preview of the team should be considered and managed effectively by the team. The team should always have a clear understanding of the external dependencies and the time in which these dependencies should be resolved, this would help reduce the complexity.
As we are making inroads into a Product based structure with Agile Scrum based framework, Story Points which is a measure of complexity is being used to identify and capture the relative complexity of requirements/stories which are taken up by the team. There would be instances that team members would have different opinions about the complexity based on their knowledge of tools and technology or any other innovative ideas to accomplish the requirement. And, the discussion is the biggest contributor to the team, and it brings out new and innovative ways of performing the tasks at hand and at the same time learning something new with every task. A simple way to manage would be to create a Wall of Reference which would highlight the requirements/stories in their respective buckets of complexity.
Hope this has been helpful