- 1 Introduction
- 2 How to Install ZenTao
- 2.1 Choose the best installation
- 2.2 ZenTao Cloud
- 2.3 One-click Installation for Windows
- 2.4 One-click Installation for Linux
- 2.5 Installation with Lampp
- 2.6 Source Code Installation (for all Systems)
- 2.7 Set up Virtualbox for ZenTao
- 2.8 Softaculous service
- 3 Upgrade ZenTao
- 3.1 Upgrade ZenTao
- 3.2 Upgrade by source code (for all systems)
- 3.3 Upgrade for one-click installation for Windows (xampp)
- 3.4 Upgrade for one-click installation package for Linux
- 4 Users and Groups
- 5 Simple Application
- 5.1 Project and Task Management
- 5.2 Bug Management
- 5.3 Product Management
- 5.4 Individual Task Management
- 6 Basic Application
- 6.1 Basic Workflow
- 6.2 Agile and Scrum
- 6.3 ZenTao and Scrum
- 6.4 ZenTao Tutorial for Rookies
- 6.5 Create a Product
- 6.6 Create a Story
- 6.7 Create a Project
- 6.8 Confirm Stories
- 6.9 Story Breakdown
- 6.10 Report a Bug
- 6.11 Manage Contacts
- 6.12 Customization
- 7 Advanced Application
- 7.1 Workflow
- 7.1.1 ZenTao Workflow
- 7.2 Personal management
- 7.3 For Product Owner
- 7.3.1 Manage a Product
- 7.3.2 Manage a Product Line
- 7.3.3 Create and Review a Story
- 7.3.4 Change and Review a Story
- 7.3.5 Story Status
- 7.3.6 Notes for Writing a Story
- 7.3.7 Product Modules
- 7.3.8 Release Plan
- 7.3.9 Create a Release
- 7.3.10 Roadmap
- 7.3.11 Manage Documents
- 7.3.12 Product Planning Meetings
- 7.3.13 Daily Scrum, Review and Retrospective Meetings
- 7.3.14 Story Reports
- 7.4 For Project Manager
- 7.4.1 Create a Project
- 7.4.2 Set up a Team
- 7.4.3 Confirm Stories
- 7.4.4 Story Breakdown
- 7.4.5 Daily Standup Meetings
- 7.4.6 Check Project Progress via Burndown Chart
- 7.4.7 Check Project Progress via Lists
- 7.4.8 Review and Retrospective Meetings
- 7.4.9 Basic reports on tasks
- 7.5 For Development Team
- 7.5.1 Project planning meeting and task breakdown
- 7.5.2 Claim tasks and update
- 7.5.3 Kanban and Tree Diagram
- 7.5.4 Create a Build
- 7.5.5 Test Task
- 7.5.6 Resolve a Bug
- 7.5.7 Manage Documents
- 7.5.8 Confirm Bugs
- 7.6 For QA Team
- 7.6.1 Bug Management
- 7.6.2 Report a Bug
- 7.6.3 Confim and Close a Bug
- 7.6.4 Activate a Bug
- 7.6.5 Locate a Bug
- 7.6.6 Test Cases
- 7.6.7 Create and Review Test Cases
- 7.6.8 Manage Test Tasks
- 7.6.9 Test Suites, Public Case Libs and Reports
- 7.6.10 Manage Test Tasks
- 7.6.11 Execute Cases and Report Bugs
- 7.6.12 Reports
- 8 Configuration
- 8.1 Maintain ZenTao
- 8.1.1 Initialize scripts
- 8.1.2 Back up ZenTao
- 8.1.3 Recover the Deleted
- 8.1.4 Update Burndown charts
- 8.1.5 ZenTao remote host
- 8.2 Deploy ZenTao
- 9 Custom Development
- 9.1 ZenTao customization
- 9.2 ZenTao Directory
- 9.3 Locate and Change Files
- 9.4 ZenTao Database Structure
- 9.5 Common Modules
- 9.6 Add Features to Menu
- 9.7 Set Privileges to Modules
- 9.8 Examples: Modify Language Prompt
- 9.9 Examples: set priority when creating bugs
- 9.10 Web Editor
- 9.11 Packaging Standards of ZenTao 1.1
- 10 Other Relevant Issues
1. Writing stories in ZenTao
In ZenTao, a default story template is offered to all users, which is,
As a < type of user >, I want < some goal > so that < some reason >.
This template is based on user story writing in Scrum development, but we adopt a relatively neutral concept.
In this template, there are three factors, roles, goals and reasons. Usually roles and reasons tend to be ignored, while goals have been paid much attention to. It will cause some problems. If roles are not defined, the design and positioning of product functions will be affected. Consequently, this product will be developed for just one user role, which is for the product manager who wrote stories. Besides, developers will get confused, if the development reasons are ignored. They would not understand why they are asked to do it, and thus it will be difficult for them to finish stories.
2. INVEST principle for stories
Except for the template mentioned above, you can also refer to the INVEST principle (Reference http://duweizhong.blogbus.com/logs/112151436.html) when writing a story.
I —— Independent
A user story should be independent from the other user story. The interdependent stories would make it quite difficult to do planning, prioritizing and estimation. Dependency can be reduced through story combination/subdivision.
N —— Negotiable
User story should be negotiable. A story card should contain a brief introduction of the story, which is defined through meetings and discussions. A card which contains much information actually reduces the talking with clients.
V —— Valuable
Each user story must be valuable for clients (both the customers and the users). One way to make user stories valuable is to let the clients write them. Once clients realize that a user story is not contractual but negotiable, they will be very willing to write them.
E —— Estimable
Developers need to estimate the user story in order to set priorities and make plans. But what makes it difficult for developers to estimate is the lack of relavant knowledge in certain industry, which could be sovled by more communication; or because the story is too big, and should be subdivided.
S —— Small
A great user story should be small in terms of workload and description, and it could be done by two/three persons. User stories bigger than the workload of 2-3 persons will cause problems when subdivided and estimated.
User stories are testable and can be finished through testing. Remember, stories that are not testable should not be developed. If you cannot test the stories, you will never know when they can be finished. An example of untestable user story is that software should be user friendly.
A well written user story is the basis of Agile development. The stories should be independent from each other and convenient for communication between developers and users. At the same time, they should be valuable for users and as small and clear as possible for developers to estimate, as well as testable.
3. Differences between a Story, a Prototyping Model and a Story Design Document in ZenTaoIn traditional project management, many product managers use software to design a prototype or a complete story design document. Then the prototyping model or document is sent to designers for web design and then to developers for coding. So what are the relations and differences between prototyping models and user stories?
- Compared with user stories, prototyping models or story design documents are considered as one unity and understood at a macro level. This is very intuitive, which is also the advantage of prototyping models.
- Since it is one unity, it cannot be divided into a navigation bar or the middle of a page, etc.
- Since it cannot be subdivded, priorities cannot be set in prototyping models. For example, some parts of a page are important while others are not, the priorities of which cannot be displayed in prototyping models.
- Since it cannot be subdivded, you cannot track the progress in prototyping models. Consequently, you don't know how much has been completed.
- Prototyping models are not flexible, which make it difficult for designers and developers to change. What they can do is to passively implement prototypes.
- Story design documents are usually very specific, which also make product managers caught up in details and reduce overall management.
Although there are some shortcomings in traditional management, prototyping models or story design documents can be the supplement for each other in actual development. Document library management has been added in ZenTao 1.2. The prototyping models can be used as design documents to be uploaded to a document library, and integrated with user stories.