The last few months at Zepel has been awesome.
Since rolling out Boards earlier this year, we have been pushing plenty of new features.
But in the last two months, we took it up a notch. We launched three features, fixed countless bugs, and re-designed our entire product.
We revamped Sprints for better visibility across disciplines. We launched List, so you can capture even the smallest unit of work and prioritize them whenever you are ready.
And to make sense of all the updates your development, QA, and designers make, we launched Progress, so you can go from task tracking to feature tracking.
At the end of every feature launch, like every software product team, we went back to our drawing boards trying to find ways to make our product better with higher efficiency. And the way we see it, we always will.
Since our users are always interested in knowing how others use Zepel so they can fine-tune their processes, we thought it was time we shared ours in the hope that you can take something out of this. Food for thought, if you will.
We will discuss:
How we organize and manage projects in Zepel
In Zepel, we have one account for our organization where all our projects are housed. We’ve organized them by teams - Engineering and Desktop Widget.
We understand everybody has a different way of organizing, a process that works for them, a preferred structure…
Some prefer to organize by squads. And some organize based on open-ended products, like Mobile and Web.
Which is why Zepel is flexible enough to cater to the needs of organizations and adapt to their processes as they grow.
How we conceptualize features and capture requirements
Teams spend plenty of time asking questions like, “What features should we build next?”, “Should we prioritize this feature over the other?”, “How much functionality should we build in the first version?”.
We heard them loud and clear. Because we were asking the same questions within our team every single day.
Whether you’re building software to sell to large enterprises or an e-commerce platform to sell cat food, features are the fundamental building blocks of software product teams.
Sure, issue tracking is a key process in the lifecycle of developing software. But it comes at a later stage - once your feature is built.
The first unassailable hurdle in building any feature is planning and capturing all the requirements. After that, each action organically leads to the next step by itself.
And since conceptualizing and planning a feature comes pre-filled with nagging questions and painful mental blocks, Zepel uses a free-flowing interface that doesn’t get in the way of thought process.
All you have to do is type and hit enter. Just like you would on a document.
We capture our feature requirements as User Stories, Enhancements, Tasks, Subtasks, or Bugs. When we find groups of work inside a feature that can be clubbed together, we put them under a Section.
And when a new task comes up and is not related to a feature, we added to the project’s List. That way, we can add it to a Sprint or push it to Board and work it whenever the time is right.
Based on the current situation and our user’s needs, we prioritize our features by using Progress.
Progress acts as the command centre for our entire team. All features in the Todo column are organized based on the highest priority. Once it is ready to be worked on, we move the feature to In Progress and set an owner to one of the developers who will oversee the completion of the feature. And of course, a duration to ensure we ship on time.
Collaborating and gaining visibility across disciplines
Once the “what to build“ question is cracked, answering questions like “who’ll build it” and “will we build in phases” are much easier to answer.
We bring in our development team, sit together, and break down each user story down to subtasks and estimate them. Based on time constraints and needs, we decide if we should re-prioritize or build the feature in phases.
We’ve written in detail about feature prioritization over here and we use a version of it within our team. If we decide to build the feature in phases, we add hashtags to denote priorities to user stories and assign them to developers.
We use Sprints whenever we decide to build the feature in phases, but we’ll talk about that in a bit.
As the feature moves from finalizing the design to building the feature, and testing it, dependencies creep up and often requires people with different skill sets to come together. And the easiest way to get team members across disciplines to work together is by allowing them to work just the way they want.
Because nothing kills productivity like sacrificing the workflow you are most comfortable working with.
Which is why, every discipline involved in building the feature gets a Board tailor-made just for them. And we add new dependencies as a subtask and push it to the respective board.
For example, when there’s a design dependency, we move the specific subtask to the design board and our designer picks it from there. And when it’s ready for the developer to work on it, our designer adds a link to our InVision artboard.
Finally, when all user stories and enhancements are complete in our Development Board, its cue for the QA team to start testing and report any bugs they find. We then use the Bug Board to keep track of bugs and fix them.
We use the Project Boards for each discipline to track their work across features. And Feature Boards for each discipline to track their work in a specific feature.
You can read more about the difference between a Project Board and a Feature Board over here.
Building features in phases with Sprints
In a perfect, simple world, you’d launch a pixel-perfect, fully-functional feature, without missing edge cases or letting bugs creep in. Unfortunately, feature building isn’t that easy.
In crunch situations, we’re sometimes forced to release the smallest version of our feature. Sometimes it’s just one feature. And a lot of times, we are forced to try and complete miscellaneous work items along with it.
We use Sprints in situations when:
- We don’t have enough time to build the entire feature.
- The feature we are working on needs another feature to be completed to be useful for the user.
- We are prioritizing those pesky little bugs we added in our project’s List.
How we keep everyone in-sync with updates
Getting updates from team members working on your feature is probably the biggest challenge of any team.
Members in our team use the Desktop Widget to be notified when new work is assigned to them and to update their progress. The development team have their work integrated with Github so when they merge their PR, work assigned to them gets completed automatically. And with Slack integration, everyone involved is notified of the update.
Making sense of all the updates as a Product Manager
Of course, we use the Cumulative chart to see if there are any roadblocks and Burnup and Burndown to see if our Sprint is progressing.
But sometimes, we just don’t prefer fancy charts and graphs. Sometimes all we want to know is the percentage of completion. And so, we use Progress to see how far away we are from completing the feature.
Since all the updates are in real-time, whether our team members use the Desktop Widget, one of our integrations, or from within the web app, our product manager can finally make sense of all those reports and updates across disciplines.
Looking back, the reason we were able to pull off three feature launches and a product redesign in a space of two months was by ensuring every discipline involved in building the feature got to work just the way they wanted. And never lost sight of the big picture.
This allowed everyone, from the product manager to developers, to work from their world view of what is needed to build the feature. And it took us from a “fix issues” mentality to following a process that allowed us to think in terms of the bigger picture.
How do you use Zepel to plan and build features? Tweet to us and let us know. We’d love to learn from you! :)