Improving Software Estimation using UML

As I have worked to coach teams on improved communication, I have started to reflect upon the value of classic software engineering artifacts and diagramming techniques. I love the benefits of visual communication. On this blog, we tend to focus on ways teams can implement agility into their flow. Many agile teams can forget the benefits that traditional UML(unified modeling language) brings. The agile manifesto challenges us to avoid comprehensive documentation. Hopefully, we’ll highlight some of the high value elements of UML.

As engineers, we can often become too focused on our implementation tools like languages and code editors. I feel it’s important for teams to decide on a few document types that guide their decisions around project scope and component responsibility. You should consider reaching for a classic visual diagramming pattern when you feel it facilitates a communication challenge with your team. At key moments, we want our teams to see the big picture. In the post, I will submit that these diagrams help your teams plan, scope and communicate more effectively.

In this post, I will advocate for the benefits and core concepts of a few high value document types. You may find it tedious to honor every exact detail that UML encourages from visual communication. Personally, I don’t find value in following UML diagramming style to the letter of the law. I leverage the visual diagramming concepts that help my team create a trusted design. We leverage the UML rules opportunistically.

The following blog posts communicate the tensions teams will feel using UML. Agile professionals seek to create value for the organization using evolutionary architecture. At times, the complete architecture will come into existence through iteration. Is it wasteful to keep the UML updated? Teams will need to decide for their culture and business context.

The Enduring Relevance of UML: Leveraging Modeling for Agile Success – This post from Visual Paradigm highlights how UML remains a valuable tool in Agile environments. It discusses how UML diagrams help visualize and document the structure and behavior of software systems, which enhances communication and understanding among team members, leading to more accurate project estimates

Is UML Still Relevant Today? How Is it Used in an Agile Project? – This blog post addresses the relevance of UML in modern software development, particularly within Agile projects. It explains how UML can be used to create just-in-time models that support current sprints or iterations, helping teams to estimate tasks more effectively

As we seek to improve communication and estimation practices on projects, I have found the following styles of UML especially helpful. The folks at agilemodeling.com have a website and model index focused on the themes expressed here.

  • Use case models : I find this diagramming style helpful to understand the desired functionalities of each sub-system. The diagram does a good job of exposing your external dependencies or integrations required between sub-systems.

  • Class diagram: In more complicated problem domains, it’s great to see a big picture of your system. Creating software classes with focused responsibilities has helped me create software that’s more enjoyable to maintain. The class diagram pattern may push the team to decompose classes and increase organization.

  • Component diagram: As many of our teams do component based UX, it’s helpful to think about the general inputs, outputs, and events connected to each component. Many front-end thinkers have encouraged the creation of “dumb components” vs “smart components.” Smart components tend to have the ability to talk to the API server, connect you to your state management solution, execute logic, execute calculations or other complicated stuff. A dumb component focuses on displaying focused elements of data. (i.e. displaying a card for the speaker on a conference website, displaying a product card). Component diagrams give you an opportunity to plan these component break downs.

  • Flow charts: While simple, flow charts continue to generate good conversations regarding the total scope of subsystems. When collaborating with my product organization, we tend to focus on user facing activities and provide brief call outs to system activities.

  • Story mapping: “User story mapping is a visualization of the journey a customer takes with a product, from beginning to end. It includes all the tasks they’d typically complete as part of that journey.”

  • Entity relationship diagrams – Simple diagram pattern focused the design of relational database tables.

Be the first to comment

Leave a Reply

Your email address will not be published.


*