At my company, we often have meetings where we brainstorm / plan for next steps for our projects. After the meetings, I feel like I have a bunch of stories to write, and creating thorough and descriptive stories with good acceptance criteria takes a long time. Is it appropriate to create a user story that just says "write stories for X project"?
The idea in Scrum is that we refine the requirements as we go along. The Scrum Guide talks about up to 10% of the team's time being spent on backlog refinement.
You shouldn't need to create a task to write stories as it is an ongoing background task that is accounted for in the velocity of the team.
I feel like I have a bunch of stories to write, and creating thorough and descriptive stories with good acceptance criteria takes a long time.
This may well be appropriate in your particular circumstances, but do remember that the idea is to add detail to a user story as late as possible. The reason we do this is that it allows us to adapt to changes.
If we commit too much detail up front then that risks:
- Creating a reluctance to accept feedback and adapt our solution as we learn more about the product
- Wasted effort if priorities change and we switch to working on other stories
As much as possible, stories (and tasks) on the board should reflect value being added to the project from the customer's perspective. Avoid adding things that are of the "to-do" variety for yourself or the team. Doing so adds clutter to the board and makes it that much more difficult to stay focused on value-add work.
That said, I have set up additional Kanban boards for teams that wish to keep track of these types of activities. Tools like Jira and Trello can be used for this purpose. And then there is the tried and true sticky notes on a spare wall.
Product Owner (PO) has product vision, PO creates Product Backlog items (PBIs) a.k.a. 'promises' to have conversations, having those conversations with the whole Scrum Team creates enabling specifications, and the Product PBIs near the top of the Product Backlog become product Increments in waiting. It seems you are having conversations, which is certainly the most important element here, but without other elements of the framework your approach lacks structure. If your PBIs aren't driven by an empowered PO with a vision, who is accountable for building the right product? Having a PBI to write PBIs it a bit 'meta' and is probably a symptom of a deeper problem.
Scrum only cares about a few artifacts - the Product Backlog (and the Product Backlog Items that are contained within it), the Sprint Backlog, and the Increment that is delivered at least at the end of the Sprint. The definition of the Product Backlog is "an ordered list of everything that is known to be needed in the product". The work to put in more work is not something that is needed in the product. By this definition, I would be able to argue against putting the work into the Product Backlog.
However, we should also consider the principles of Transparency and Openness. It may be beneficial for all, both inside the team and outside, to have a good idea of what work the team is doing. Some work is regular and ongoing, while other tasks and work is more defined and has deadlines or explicit outputs that people are depending on. Tracking this work may be helpful to the team to see what everyone is working on.
At the end of the day, I would recommend asking the team. It also depends on the tool(s) that you are using. However, I would try to figure out ways to make the work of the team visible to the appropriate stakeholders in an appropriate manner. That may be using the same tool as you use for the backlog, but applying filters to ensure that these items don't interfere with the way the other users interact with it. Or it may be using an alternative tool.