What tools do you use to write down the Scrum events reports?
Hello everyone!
I spend a lot of time writing down reports of the Scrum events, to keep the memory of what was discussed, what was eventually decided, what topics are still to be discussed, etc.
I was wondering what tools you, ladies and gentlement, would recommend for that purpose (what are you using, you?)
Thanks!
* ladies and gentlemen!
Does it really take so long to implement an adaptation that this becomes a significant issue, and team members lose track of what they've decided to do?
Depends on what we talk about, obviously.
Anyway, various different topics are discussed during the different Scrum events.
I don't find safe to let the decisions unwritten, and to rely on people's memory. Especially when those decisions can't be implemented immediately.
Moreover there can be people on vacations, for example.
The question was : what tools do you, people, use to record the outcome of the discussions.
If you, Ian, don't use any tool and don't write anything down, that's already an interesting information for me, thanks.
What types of things do you or the team feel must be written down? In my experience, very few things need to be recorded for use past the event.
Sprint Planning, ongoing refinement activities, and the Sprint Review could result in new Product Backlog Items, but those are recorded in the Product Backlog, however the team manages that artifact.
The Sprint Retrospective and the Daily Scrum may reveal impediments and opportunities for improvement. I've found it helpful to record those in a backlog so the team doesn't lose track of lower priority improvement opportunities over time.
What other types of things would you want to record?
Hello,
Discover the tools that ignite your reports with passion and efficiency:
-
Digital notetaking: Embrace Microsoft OneNote, Evernote, or Google Keep for elegant organization and delightful ease.
-
Collaborative bliss: Explore Google Docs, Microsoft Word Online, or Notion for real-time editing that harmonizes minds.
-
Simplicity's allure: Markdown's minimalist wonder shines in Typora, Visual Studio Code, or Jupyter Notebook.
-
Scrum's magic: Jira, Trello, or Asana offer tailored features to seamlessly track discussions, decisions, and tasks.
May your journey be joyous, for through heartfelt writing, the spirit of Scrum flourishes.
@Thomas,
To answer your question "What types of things do you or the team feel must be written down?"
To craft my own to-do list as an impediment-remover, I should remember what are the impediments that I should take in charge,
There can be propositions to master the retrospective in a new format (then, we would implement that only after 3 weeks),
Ideas could arise that need to be matured and re-discussed, etc.
In my (short) experience, there are a lot of ideas, suggestions, decisions, that are outcoming from the Scrum events.
I'm a little bit puzzled now, then...
What do you mean, concretely, by "backlog", when you say "I've found it helpful to record those in a backlog", please?
Forgot to precise that my team is 100% remote.
The following is my opinion and I realize that not everyone agrees with me. But in my 35+ years of software development I have found that the most important information will be captured in the place where it will be most useful. Also if a topic is brought up once but no one remembers it, then it probably wasn't worth capturing anyway. People tend to remember things that impact their ability to be effective and will deal with it.
Anything that is related to the Product should be captured in the Product Backlog. The Product Owner can do that work or can delegate it to others. In my experience, the Product Owner or Developers will create most of the items in the Product Backlog. These items usually come from the Sprint Review or even Sprint Planning.
Retrospective topics are no longer useful after the Retrospective ends. If it was something important that the teams wants to do, there should be a plan prepared for how to carry it out while in the Retrospective. It lives on as a team agreement.
Daily Scrum topics will become part of the Sprint Backlog or be carried out that day.
Sprint Planning topics will be captured as part of the Sprint Backlog or put into the Product Backlog. If the topic is about work plans, they really should only be for the first day to get the team to their first Daily Scrum.
I don't find safe to let the decisions unwritten, and to rely on people's memory. Especially when those decisions can't be implemented immediately.
This is a personal opinion and I respect it. But it also could interfere with the ability for helping people become self-organized and self-managing. If you constantly remind them, then they will start to rely on you instead of their own capabilities. I prefer to rely on people's memory because if it is important enough to need action, they will be reminded about it when that action is not done.
To craft my own to-do list as an impediment-remover, I should remember what are the impediments that I should take in charge,
This is a common misconception. The Scrum Master is not responsible for actually most impediments. They are accountable for ensuring that the impediments are removed but the people that are most impacted by that impediment are usually much more effective at working on the removal. However, if there are some that you need to deal with then add them to your personal to-do list. Personal to-do lists really shouldn't contain work that is needed for the Scrum Team during the active Sprint. That is why the Sprint Backlog and the plan to do the work is created.
Ideas could arise that need to be matured and re-discussed, etc.
Again, if these ideas are important enough, they will be present in people's minds. If they aren't important, do you really need to keep a list of things that no one cares about anymore?
As for what tools to use for this I have no suggestions. Use what ever tools your organization has chosen for maintaining the Product and Sprint Backlogs. Use tools that are available from your organization. I'm willing to bet that your companies productivity suite (i.e. Microsoft Office, Google Workplace, etc) will have tools for maintaining personal to-do lists.
I would agree with Daniel. The Scrum Master is not an impediment-remover. The Scrum Master helps the team overcome impediments but doesn't necessarily remove them on their own. Since the impediments are things that impede the team, I would turn to the team to understand what the best way to keep track of the things that need to happen to get over or prevent impediments.
A lot of the teams that I'm working with and worked with most recently use Jira to manage their Product Backlog. They have found that keeping track of impediments, the work needed to resolve those impediments, and other ideas for improvement are best tracked as Issues in Jira, using the tool's concept of Issue Types, Labels, and Workflows to keep track of them in the same place as the work they are doing on the product.
Since I'm not a fan of going out and buying tools unless needed, I'd recommend working with the teams to understand what tools you have available and how they can be used to solve the problems that you are facing. If, after experimenting with what you have available, you find that they are lacking, then you can consider buying additional tools to help support the process. But making sure you have a clear objective for what you want to do and ensuring that all stakeholders are involved in crafting that objective and measuring changes for success is crucial.
Hi. It is important to understand that Scrum master is NOT the secretary or book keeper for a Scrum team.
If Scrum is set properly, every member of the team should be able to upload, create and move items in the jointly available project database-usually notorious Jira, or Excel(my favorite scrum tool ever), which I personally always suggest as back up, or other jointly accessible software.
In most cases the tool you use should be able to generate updates like virtual Kanban board or burn down / burn up charts and cumulative graphs automatically, someone just needs to program them properly. Not necessary scrum master
This material should be available to stakeholders to see at any times, so the update and development of the project is constantly transparent not only for a team members but to everyone
This is a best way to ensure Transparency, inspection and eventual adaptation
The actual Scrum events can be recorded on video, and uploaded to the database as well. Additionally the scrum team members-not necessary the scrum master, but any member of the team, can write short summaries about most important things which were discussed.
As for removing impediments: the Scrum master should of course remove impediments if there is an understanding that developers cant remove them using their own force, while scrum master is capable of doing that.
Whatever is best for meeting Sprint goal and producing valuable increment should be done even if it breaches the letter of Scrum guide-and removing impediment don't even do it.
But considering that any such situation is not a good thing, it should be treated as exception addressed to at Retrospective. And its a good idea to identify the problems which led it it, and add them to sprint backlog as non functional item meant for improving Scrum team during the Sprint(you can do that)
For documenting Scrum events reports, various digital tools are available, including but not limited to project management software like Jira, Trello, or Asana, which offer features tailored to agile methodologies. Additionally, collaborative document editing platforms like Google Docs or Microsoft Teams can facilitate real-time recording and sharing of meeting outcomes. Ultimately, the choice of tool depends on factors such as team preferences, accessibility, and integration capabilities with existing workflows.