- 1. A Brief Overview of ZenTao
2. Best Practices Comparison: ZenTao VS Jira
- 2.1 Best practices of Project in ZenTao vs Jira
- 2.2 Best practices of Workflow in ZenTao vs Jira
- 2.3 Best practices of Stories in ZenTao vs Jira
- 2.4 Best practices of Roadmap in ZenTao vs Jira
- 2.5 Best practices of Users and Roles in ZenTao vs Jira
- 2.6 Best practices of Reports in ZenTao vs Jira
- 2.7 Best practices of Dashboards in ZenTao vs Jira
- 2.8 Best practices of Search in ZenTao vs Jira
- 2.9 Best Practices of Agile in ZenTao
- 2.10 Best Practices of Waterfall in ZenTao
- 2.11 Best Practices of Automation in ZenTao vs Jira
- 2.12 Best Practices of Requirements & Test case management in ZenTao vs Jira
- 3. Use cases Comparison: ZenTao VS Jira
- 4. Get started with ZenTao
- 5. Import Jira Data to ZenTao Tutorial
- 6. Reference: Glossary of items in ZenTao VS Jira
1. Agile Stories: Definition, Examples, Templates in ZenTao and Jira
1.1 The definition of stories in Jira
Stories, also called "user stories", are short requirements or requests written from the perspective of an end user. When we talk about stories in Jira we have to mention epics and initiatives. Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories). In the same way that epics are made up of stories, initiatives are made up of epics. In many cases, an initiative compiles epics from multiple teams to achieve a much broader, bigger goal than any of the epics themselves.
Image source: Stories, epics, and initiatives
1.2 The definition of stories in ZenTao
Stories in ZenTao include 3 hierarchies -- User Requirements ，Software Requirements，Sub-Requirement. User Requirements are the requests from the perspective of an end user, meanwhile, the stories from the non-product staff can also be called user requirements. After reviewing, splitting, and refining the user requirements, here we get the software requirements. Software requirements will be handled directly by developers.
Sub-requirements represent a smaller granularity. There is also the concept of modules in Zen Tao.
Modules can be split infinitely. If the three-level requirements are not enough to express, you can manage the requirements with the concept of modules.
1.3 Examples of an Agile story in Jira
- iPhone users need access to a vertical view of the live feed when using the mobile app.
- Desktop users need a “view full screen” button in the lower right-hand corner of the video player.
- Android users need to be linked to apple store.
The above stories are all related, and could all be considered individual tasks that drive toward the completion of a larger body of work (an epic). In this case, the epic might be “Improve Streaming Service for Q1 Launch.”
If you were reporting your team’s progress to the Head of Engineering, you’d be speaking in epics. If you were talking to a colleague on your development team, you’d speak at the story level.
1.4 Examples of an Agile story in ZenTao
- “The user needs a register function”. The above story is a typical User Requirement. The non-product-related staff will input the story data into User Requirement, then the product owner will refine and review the story and split it into Software Requirements below:
- The registration page needs to have fields including phone number and email.
- The phone number and email need to be valid to receive the verification code.
Software requirements flow to the Dev team and the developers start their coding work.
You might want to go further and optimize the process of creating stories/epics using automation. There are hundreds of automation rules in the Jira Automation Template Library.
However, we don't have the automation templates to create user requirements/software requirements in ZenTao. Zen Tao's requirements management uses a fixed process and is the best practice of agile concepts.Every user requirement needs to be analyzed and viewed by PO, and not all the user requirements will pass the review to flow to the software requirement pool. We have to admit that some user requirements are beyond the Dev team's ability and require further negotiation, but that's precisely the behavior responsible for end users.
2. Working with issues
2.1 Working with issues in Jira
Organizations and teams break down pieces of work into issues. In Jira, issues can represent tasks, software bugs, feature requests, or any other type of project work that needs to be tracked. Issues can also have sub-tasks that are assigned and tracked individually. For Scrum teams, you might like to estimate your issues by story points to help you predict how long portions of the backlog might take to be delivered. At the same time, you can rank your issues in order of priority, or flag issues, transition issues, and filter issues.
2.2 Working with issues in ZenTao
Different from Jira, we don't really have an exact concept of "issue" in ZenTao. In other words, we call "issue" different names in different processes such as stories, cases, tasks, and bugs, they are our four key concepts as well. Of course, all of them are well-tracked and even go further than Jira. Let's take an example of tasks, when the software requirements fall into the exact execution (iteration), they could be broken into tasks and assigned to developers. Developers will update the status of tasks when they start their coding, at the same time, they going to record the man-hours cost and man-hours left in the effort log for better estimation. Of course, stories, cases, tasks, and bugs in ZenTao can be ranked in order of priority and searched by different criteria. What's more important, there are various reports including pie charts, bar charts, and line charts that can be viewed as a reference for your better tracking of working items.