From Preparation, Refinement to Estimation
Before development teams of an enterprise organization are ready to pick up their work, the whole process is going. A process that is essential before a developer can write its code.
After working for big enterprise organizations in the Netherlands (Rabobank, ANWB, Nato, Ministry Of Health, Wealth and Sport) since 2014, I've seen how those organizations prepared their work for their development teams.
This is not a guarantee that this works in your organization! Even though you are working Agile with the Scrum or Kanban methods, you have to put in the work and adopt change when needed. I learned a ton from it, so I love to share that workflow with you in this post.
Table Of Contents
Foreword
This workflow is the baseline that I used in all organizations I worked for. From small to big, it doesn't matter. It's essential to have a workflow working for both the "business" and the "development" team.
- When I say business, I mean people who know how the business works, how their clients interact with their products, and people responsible for these products. Most organizations call those people Product managers or Product Owners (if they adopted Scrum).
- When I say, d*development team,* I mean people who are in a development team. These are developers, testers, scrum masters, team lead, designers, and more along those lines.
1. Preparation
Almost every person on earth knows an excellent preparation will make your changes to success much bigger than if you don't.
Working in a small organization is easier (I don't mean that it's easy) than working in a big organization. So if you are in a small organization and want to grow, start soon with that preparation. Always keep in mind that it's not only clear for you but also others.
preparation for the business
The business people must do their preparation way before the development team has to do something with it.
If your organization works with Github, Azure Devops or Jira, make sure this work is being done in the "backlog". Or, if product managers prefer to work on their visions and features in Word or Excel, let them do that.
Make sure this preparation work doesn't interfere with the work of the development team.
What should be prepared
It's hard to define what a product manager or owner should prepare if you don't know an organization. But I will try to explain the most general things.
A feature should describe it's...
- Goals It would be best if you defined what the goal is for the user. Why is this important for a user? What goal should a user accomplish? (a development team likes to know a bit of the reasoning behind a feature)
- Scenario's It's important to write different scenarios on the vision the user should follow to accomplish its goal. This also helps to set guidelines for the team on what they can expect a particular feature should work.
- Devices Nowadays, the different types of devices that can interact with an application are massive. So it would help if you thought about how the development team should handle those different screen sizes.
- The un-happy path Don't forget to think about handling errors because systems can be down, or users click on buttons you don't expect. This part is super hard, but the development team can help with this if you're missing this part.
- Forms When your application has formed. Well, most of them will have a few, no question about that. You must think about the requirements for this. Can a user send an endless string with all kinds of characters, or does it have a maximum? For a development team, these details or super important.
It's not that the business should know every single detail. But all the known facts must be written down. As long information is not written down, but in people's had, people will guess.
When people are going to guess, as a product manager, you're going to be sure your expectations aren't met.
2. Refinement
The main priority for this refinement is that the business and the development are on the same page and create one complete package of information, so no one has to search for all kinds of documents.
When the business has done all the preparation, it's come to a phase that the development team will see that preparation for the first time.
In my experience, it's very vital for the success of a product or service that development will plan time to read through all that documented information. For sure, they will come with questions about specific details. Yes, that is a good thing!
The responsible business person must create multiple user stories on the backlog of the development team. Mainly if the business person worked, it's features/ideas out in a Word or Excel document.
Breaking features down into smaller pieces will help developers to fully understand why it's so important that they need to build it. If the parts are too big, developers can't fully grasp the ideas and make reasonable estimations.
It's good to plan a "refinement" meeting with the responsible product manager or product owner to discuss those details with the development team. Being in the same room or online discussion will ensure that the development team asks questions to the source.
When details are not precise, the development team should clarify the information in the backlog. Sometimes it can help if they add details, screenshots, or external documents.
Now that the development team and business agreed on the plan of the feature, they should be able to give an estimation.
3. Estimation
Estimation is one of the hardest things in software development. (I'm sure doing estimates is hard for every human on this planet 🌍)
Making estimations requires developers to understand the feature they need to make fully. They must have user stories that are broken down into smaller pieces. This helps to make better estimations.
If the user stories are too big:
- Developers tend to have loads of questions instead of a few
- There will be huge gaps between the estimations of the team
- Developers will see big problems
If the estimations are too far from reality, people like product managers & product owners are not happy.
It's also essential to know that it can take a development team a lot of time to learn to work together. But in that state of perfect collaboration, the estimations in a group will be better.
For all these managers that require perfect estimations, please don't expect this from your team. It requires years and years to get good at estimates. This is only possible if the techniques and domain stay the same.
If developers switch between techniques, domains, or projects, it stays tough to estimate your work.
So for all the managers that want their team to do estimations, you need to create optimal circumstances and prepare all the work for the team. Make sure that they don't have to dig deep for their information, which will cost a lot of time. Prepare and package all the information they need in 1 place. This will help for preparation and estimation.
Conclusion
I hope that this process will help you shape the workflow your team needs as a developer or manager.
I would highly recommend using an Agile framework that helps you and your teamwork in a great way to deliver valuable software projects. I'm a big fan of Scrum and Kanban.
If you have any questions about this workflow, please let me know. Any suggestions are more than welcome!
The success of a software development project is in the preparation phase. If all the information is available in one place, it will prevent a team from losing valuable time on searching. This will help the team make better decisions.
An Agile framework like Scrum or Kanban can help with organizing the process around a development team. I love both!
Thanks!
*I hope you learned something new or are inspired to create something new after reading this story! 🤗 If so, consider subscribing via email (scroll to the top of this page) or follow me here on Hashnode.
*
Did you know that you can create a Developer blog like this one, yourself? It's entirely for free. 👍💰🎉🥳🔥
If I left you with questions or something to say as a response, scroll down and type me a message. Please send me a DM on Twitter @DevByRayRay when you want to keep it private. My DM's are always open 😁
Top comments (0)