By: Ivsen Platcheck, MSC. ENG.
June 30th, 2022
Along all my working years, and they are a lot of years, I’ve been working with project cycles. As an executor, as a manager, a mentor, or even as a kind of coach.
I began to work on projects with no technique, no methodology, or workflow framework. Then, after training, and lots of studying, I started to use some of the Microsoft Framework Solution (MFS) artifacts, tools, and practices.
Then, after a training course in Project Management, I started to use PBI/PMBOCK principles, artifacts, tools, and ways to work. After learning further by reading, and attending small events and classes, I started to add agile methodologies and ways to work.
Ever since I started to work on projects, the most challenging task was to describe the target, the object, the product, anyway the values I was aiming to deliver. I learned to make a most complete description of the goal we had to achieve.
When I learned to program with UML, I studied the theory for Use Case. I studied a lot and with one author, Alistair Cockburn [AC01], I adopted the textual Use Case, which I adopted to all my projects from then.
The Use Case artifact helped me to define with great accuracy, at least, the major features needed to achieve the goal for the project, as desired and defined by the Stakeholders. With the Use Case artifact, I could map most of the features, and my productivity grew, my delivery speed also increased with much more success and less re-working to solve some mistakes or failures along the cycle.
Along the way, I learned about the Agile Methodologies, and one artifact caught my eye, the User Stories [CM01] and [PJ01]. The Use Case helped me to build a model, but it still missed some information to help understand the motivations and some subjective information to help decide ways to go and make decisions when technical issues should demand it.
I decided to use both artifacts to start the planning for a new project cycle. With the User Story artifact, I used to write all information, in plain language, about the desires, demands, minimum features, and the complete product value they need to fulfill their expectations for the result of the project cycle value deliver.
Using the information listed, unstructured, at first, on the User Story, I used to build the use case. This artifact I use to write as a sequence of steps when using the product. Those steps lead me to the requirement list and the prioritizing the items for the Product Backlog. Those times, I used some artifacts which eventually were incorporated into the workflows, frameworks, methodologies, etc.
Those artifacts showed themselves invaluable, to list functional and non-functional requirements and define the scope for the project.
When I decided to invert in Agile Management learning, I felt all my learning process took me here, where I am now. I learned SCRUM and started to practice using my elected tools to start planning the project due for the product, service, or value in general demanded by the stakeholders, brings a lot more accuracy in fulfilling the stakeholder’s demands and desires, a better prediction for time to deliveries, minimum viable product, complimentary iterations.
The Product Owner, with the Scrum Master’s proper assistance, has all the information to create the Product Backlog.
The Product Backlog accurately built may lead to better and better-estimated sprints. I keep using this scheme, associating User Stories and Use Cases, refining the inner stories, made my project cycles better every more I learn from each cycle, each sprint.
I know User Stories are only optional to the Scrum Framework definition, and for less complex projects it may look like a useless bureaucracy, but my experience along all those years is that it helps, even when dealing with less complex projects. For more complex, larger projects I strongly recommend using those artifacts to build the plan of work, and the map of the framework flow.
I must warn, therefore, the use of these tools and techniques described is a good start, it will give the project a really nice possibility to succeed. But it is not a guarantee that the project will actually succeed. It’s a good start, but the next steps are as much important to receive full attention and focus, for the project to achieve its goals.
Reference
AC01 – COCKBURN, Alistair, “Writing Effective Use Cases”, Addison Wesley, 2000.
CM01 – COHN, Mike, “User Stories Applied for Agile Software Development”, Addison Wesley, 2004.
PJ01 – PATTON, Jeff, “User Story Mapping”, O’Reilly, 2014.