#2. Project artifacts and their importance
An artifact is an artificially created item with meaning attributed to it by its creators. It is used to improve efficiency, reduce explanation time, condense text, etc. In software development, common artifacts include:
The range of interpretations of each of these artifacts is proportional to the number of project managers. Hundreds of books and thousands of articles have been written about each of these artifacts, but we will keep it short and straightforward.
EPIC
Epic is a large piece of the software that has to be development. In every project, there could be many epics. The epics are written by Business Analysts, Product Managers, or Product Owners.
Here's an example:
Project: "mobile application UBER".
Epic: "Registration System," "Interactive Map," "Payment System," "Rating System," and so on.
Usually, the description of an epic runs along the following lines:
Project: "mobile application UBER".
Epic: "Registration System," "Interactive Map," "Payment System," "Rating System," and so on.
Usually, the description of an epic runs along the following lines:
"Registration system - it is designed to ensure the possibility of registration through social networks, with mandatory verification of a mobile phone number."
A competent manager writing the epics should make sure they include general information about everything to be taken into account. If desired, info involving economic, legal, strategic, and other matters can be added. Example:
Registration system.
The target audience consists of men and women in 65% / 35% proportion. The target age range is 18 - 45.
We need to bear in mind that our strategy envisages launch and expansion in China, where Facebook is prohibited, but there are local social networks such as Weibo and WeChat.
For analytics, we will need any information that can help us identify the specifics of the user group, as well as facilitate the registration process for target audience users.
The target audience consists of men and women in 65% / 35% proportion. The target age range is 18 - 45.
We need to bear in mind that our strategy envisages launch and expansion in China, where Facebook is prohibited, but there are local social networks such as Weibo and WeChat.
For analytics, we will need any information that can help us identify the specifics of the user group, as well as facilitate the registration process for target audience users.
And so on.
Many might wonder if a programmer genuinely needs this info. The short answer is yes.
If we want a quality product, then the team needs to act as a team, and the company can only be successful if all the team members share the same information about the product nature and it's target audience.
We don't have to disclose confidential info, but if we openly express the objectives of our work, the only risk is that we'll receive helpful advice from our colleagues. Therefore, it's important not to let our egos get in the way, or else we might be risking our success.
If we want a quality product, then the team needs to act as a team, and the company can only be successful if all the team members share the same information about the product nature and it's target audience.
We don't have to disclose confidential info, but if we openly express the objectives of our work, the only risk is that we'll receive helpful advice from our colleagues. Therefore, it's important not to let our egos get in the way, or else we might be risking our success.
User Story
This artifact contains the requirements for the feature development. One Epic can contain dozens of user stories. A user story is compiled by the Product Owner, Product Manager or Project Manager (although in the ideal world the project manager should not do this).
Unlike Epic, the User Story contains precisely the information required for the programmer to develop a feature.
Usually, user stories are written in the first person, e.g. "As a user .... I would like to .... in order to ...", however, if the development team agrees, a different format may be used.
An example of a user story for "Payment System" EPIC:
Usually, user stories are written in the first person, e.g. "As a user .... I would like to .... in order to ...", however, if the development team agrees, a different format may be used.
An example of a user story for "Payment System" EPIC:
As an UBER user, I would like to be able to access the Payment Methods page from the left-hand menu. On this page, I would like to see the following buttons:
"Add new card"
"Add PayPal Account"
If I have already added payment methods, I would like to see them in the list, with the date of addition. Also, I would like to see a button for deleting the payment method, which, when clicked, would open a confirmation window with the text asking “Are you sure you want to delete %method% payment method?" with “Yes / No" action buttons. Where %method% I want the system to show the name of the payment method that is being deleted.
"Add new card"
"Add PayPal Account"
If I have already added payment methods, I would like to see them in the list, with the date of addition. Also, I would like to see a button for deleting the payment method, which, when clicked, would open a confirmation window with the text asking “Are you sure you want to delete %method% payment method?" with “Yes / No" action buttons. Where %method% I want the system to show the name of the payment method that is being deleted.
It is essential to bear in mind that every single detail is essential when it comes to structuring a user story, as any missed detail can lead to considerable time being wasted by the programmers working on it.
For instance, when the above-mentioned user story reaches the programmers, they may ask questions such as, "Can I attach multiple bank cards and/or PayPal accounts?", "Should they be arranged by date of addition or by name?" and "If ordered by date of addition, should we display the cards first, then the PayPal accounts?".
If these, and many similar details are not specified, the team will have to spend extra time and effort to get that information, which can cause a story that was initially estimated as taking "5 hours of work" to drag on for days, weeks, or months. Consequently, it is important to consider the following questions when writing a user story:
For instance, when the above-mentioned user story reaches the programmers, they may ask questions such as, "Can I attach multiple bank cards and/or PayPal accounts?", "Should they be arranged by date of addition or by name?" and "If ordered by date of addition, should we display the cards first, then the PayPal accounts?".
If these, and many similar details are not specified, the team will have to spend extra time and effort to get that information, which can cause a story that was initially estimated as taking "5 hours of work" to drag on for days, weeks, or months. Consequently, it is important to consider the following questions when writing a user story:
- How will this component of the system work?
- What questions will a programmer have?
- What questions might designers have?
- What questions may arise when we test the system?
- What questions could the end-users of this component have?
By the way, the manager needs to ask him/herself the last question many times, until he has a clear understanding of how this component should work.
Task
Tasks are small chunks of the user story. For example, for the development of the "Payment Methods Page" history, you may need dozens of tasks assigned to designers, programmers and QAs. Example:
Tasks are mainly drafted by technical specialists and developers, with direct or indirect participation of the Project Manager or Product Owner. Ideally, if the user story is written in such a way that no one has any questions, all tasks can be written by the developers.
The developer responsible for dividing up the tasks is usually the Lead Developer (Team Lead).
The developer responsible for dividing up the tasks is usually the Lead Developer (Team Lead).
Sub-Task
A sub-task is the result of splitting a task into smaller components. It's not always necessary and is at the discretion of the Team Lead.
Bug
The type of an error when the system behaves not as per design is called a bug. As bug example, imagine that someone tries to click 'Attach PayPal', but in the menu that appears, they see a request to attach a bank card instead. The job of QAs (and testers) is to locate any such mistakes, and overall this process takes a significant amount of time in the software development life cycle.
In addition, if the app is already up and running, the users of the software might come across such issues and report those to the support team. No matter how the bug was found, we have have to register it in the system in accordance with already agreed processes.
We have now reached the end of our discussion on project artifacts. Every year, some groups in online forums claim that EPIC term is outdated and that the only correct approach is to use the 'Goal/Experience/Initiative/Feature'.
The truth is, whatever term you use, as long as you understand it, that is all that matters. The important thing to remember is that the product management structure must be as simple and understandable as possible.
The truth is, whatever term you use, as long as you understand it, that is all that matters. The important thing to remember is that the product management structure must be as simple and understandable as possible.
In our next article, we will briefly examine online project management systems. All the artifacts we have just discussed will be put in context.