How we developed Backlog’s Board feature (Part 1)

As you’ve hopefully seen, we recently released a new feature in Backlog called Boards. These Kanban-style boards provide a helpful visual of where your tasks are in your workflow for each Backlog project. We had a lot of requests for this feature, and we were really excited when it came time to develop it.

As the team leader in the development of this feature, I want to share our process from kick-off to final release.

Every team is different and has to find a style that works for them. But hopefully, this information will be useful to you and your team when you’re ready to develop your next product.

Here’s what I’ll be covering: 

Backlog Board reflects changes made by other members in real-time.

Project development methodology & tools

For most projects, our development teams use our own version of Scrum. We work in one-week Sprints to develop the product iteratively and hold regular meetings on Mondays and Wednesdays for reviews and discussions.

For project management and code version control, we naturally use our own tool Backlog

For communication, we use our chat app Typetalk. All of Nulab’s products are integrated, so we also set up Typetalk to send us notifications about key Backlog updates — like new tasks or commits in the Git repository. That way everyone can stay in the loop on updates.

We use Typetalk to communicate, give feedback, and get updates on our Backlog projects.

In addition, we use our collaborative diagramming tool Cacoo. Cacoo helps us create and collaborate on wireframes, UML, workflows, specifications, etc., as text and verbal communication alone are seldom enough. We can also embed these diagrams in both Backlog and Typetalk wherever we need. These diagrams help us communicate more clearly and efficiently throughout our projects.

Project kickoff: Determining the scope

We started off the project with a project inception deck created in Cacoo. We had all team members and internal stakeholders meet to define the project scope, including features, priorities, and constraints.

Then, we added the diagram to our Backlog project’s Wiki homepage for easy reference.

The goal of the project is to bring ease of collaboration to everyone.

Want to learn more about managing your project’s Wiki? Check out our Wiki Guide.

Wireframes: Determining the rough specifications 

Next, we created some rough wireframes of the product in Cacoo and discussed them with the team using comments and mentions. After enough feedback, we defined the requirements of our Minimum Viable Product (i.e., MVP

As with our inception deck, we added this wireframe on our project’s Wiki homepage.

Cacoo diagram explaining the specifications for the Issue Type filter.

Milestones: Determining the project’s milestones

Next up was setting our project’s milestones. 

Since our project was considered complete when the Board feature was released to all Backlog spaces, we designed our major/release milestones around this goal.

Example

Milestone End date Alpha release XXXX – XX – XX Group 1 release XXXX – XX – XX Group 2 release  XXXX – XX – XX

The first milestone we set was to release the Alpha version of the Board to our internal Nulab staff. We wanted to test the product internally first to gather feedback and make improvements before releasing anything to the public. Once we were confident in the product’s stability and usefulness, we then planned

Continue reading

This post was originally published on this site