To do this, we use the standard “status” property on our feature cards with the following values: It also means ensuring everyone knows what the most important thing to work on next is. This means having enough “dev-ready” features to start coding, stretching out at least one or two sprints ahead. One of the primary goals of project management is to keep your team unblocked. The most important thing right now, as we start out, is to make sure our developers have rich enough definitions of the initial features so they can get to work productively. We are continuing to iterate our process as we go. The Focalboard team formed in late April, and we were able to use Focalboard to quickly get everyone on the same page in less than a couple weeks. As a result, we know everyone is working off a single source of truth for the project and always has access to the most current information.
#MATTERMOST GITHUB UPDATE#
Now, when new information comes up during discussion, we can quickly update cards, often in real time. But we found that the Markdown card contents were more than sufficient for recording all the important information in one place. Initially, we wondered whether we should put the specs and other details into Google Docs and link to them. Once the features were in cards, we easily added layers of organizations to each of them (e.g., epics, links to GitHub issues, and more detailed requirements). We originally had a draft of our v1 roadmap in a Google Doc, but it took less than a couple of hours to copy and paste the information into about 80 total cards. Next, we dumped all of our ideas into cards. We then created a Focalboard attached to that channel and added a link to the header. The first thing we did, like all good project teams, was to set up a channel for the project and invite all our team members and stakeholders. It turns out that the reality of using the v0.6 feature set to manage the project was. In all honesty, we expected this process to be much harder than it was.
Luckily, we had the means to fix those limitations and implement those features ourselves. We knew going in that using Focalboard in place of a more mature system like Jira would mean dealing with missing features. Of course, there is a long tradition of “eating your own dog food”-or, as we prefer to say, “drinking your own champagne.” When we looked for a project management solution to coordinate the development of Focalboard itself, the choice was clear: We would use Focalboard to build Focalboard (just like Mattermost uses Mattermost to build Mattermost). One of the most common use cases for each of these tools is managing projects. We created Focalboard to be a self-hosted, open source alternative to tools like Trello, Notion, and Asana.
0 kommentar(er)
