#2. Project artifacts and their importance
An artifact is an artificially created object that is endowed with meaning by those who created it. For example, a scheme, document, or prototype - these are all artifacts. In essence, an artifact is a concise yet wide-ranging concept whose sole goal is optimization. Optimizing the time for explaining what you need, optimizing the text devoted to describing something, and so on.
For the software development process, we derived the following general set of artifacts (the pictures are secondary, but I love them!):
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 is a large component of the software development process. In each project, there may be several epics that sum up the expected results of the project.
Epics are compiled 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:"Registration system - it is designed to ensure the possibility of registration through social networks, with mandatory verification of a mobile phone number."
Ideally, the Epic should contain sufficient information to enable the team that works on the Epic to understand not only what needs to be developed, but also why. Info may include research results, brief extracts of statistical data, and so on.
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.
And so on.
A competent manager engaged in the compilation of epics will ensure that they include general information about all that one needs to take into account when working with the component. If required, details related to legal, economic, strategic, and other information can be added.
I can hear you exclaiming: WTF! does a programmer really need this information?
And probably the average programmer will also be worried, thinking: "why do I need all this? Cancel lunch, I urgently need to write code!"
Unfortunately, the fact is, that if we want a quality product, then the team really has to act as a team, and the company can only flourish if it has a devoted team. In short, there's no alternative.
We should aim to be as transparent with the team as possible. I'm not suggesting that in epics or anywhere else, you should reveal commercial secrets. Still, if we openly state the motives of our actions, the only risk is that we'll receive colleagues' valuable advice. So we need to leave our egos to one side: otherwise, the only thing we are risking is our success.
This artifact contains the requirements for developing the component.
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 Story contains precisely the information required for the programmer to develop a component.
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.
For the epic "Payment System," the following Stories might be relevant:
"Payment methods page," "Attaching a bank card," "Attaching a PayPal account," "Ordering page," and more.
Let's take the example of the user story "Payment methods page":"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
Opposite the added payment methods, I would like to see a button for deleting the payment method, which, when clicked, would open a confirmation window with "Yes / No" options."
As a general example, this is probably enough. Learning how to structure a user story is a matter of experience that comes with time, but it is important to be aware that every single detail is vital. If you miss out on detail, the consequence can be measured in minutes/hours/tens of hours for programmers working on the Story. When the above Story reaches the programmers, one of the first questions they will ask is, "Can I attach several bank cards and/or PayPal accounts?" followed by: "And in what order should we arrange them? By date of addition or by name? If by date of addition, can cards and PayPal accounts alternate, or should we first show the cards, and then the PayPal accounts?". All this and dozens of other questions will undoubtedly arise in the developers' minds, because these details haven't been specified. As a result, additional time and effort by the team will be required to clarify each of these questions, and so a story that was estimated at "5 hours' work" can drag on for days, weeks or even months.
Thus, to write the perfect user story, the manager needs to be able to answer the following questions:
- 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 himself the last question many times, until he has a clear understanding of how this component should work.
Tasks are segments of the user story. For example, for the development of the "Payment Methods Page" history, you may need dozens of tasks involving designers, programmers and testers.
Tasks are mainly drafted by technical specialists and developers, with direct or indirect participation of the Project Manager or Product Owner (if necessary). Ideally, if the 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).
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.
This is when an error has occurred in the program. For example, we click on "Attach PayPal", but in the menu that opens, we see an invitation to attach a bank card. Oh dear.
The key role of testers is to look for errors: this is an essential role in software development.
In addition to the testers, bugs are sometimes detected by the users themselves, who then write to the support service with questions such as: "I didn't open this window, where are my profile settings?"
Regardless of who found the bug, at some point, responsible for documenting this kind of problems adds a bug as another task that the development team fixes in the order of a certain consistent queue.
And that's the end of our discussion of project artifacts. Every year, some or other online discussion group fervently declares that Epic is outdated and that the only correct approach is to use "Goal / Experience / Initiative / Feature". In fact, it doesn't matter how you call it, as long as you understand what you are doing. The one thing to remember in all of this is that the structure should be as simple and understandable as possible.
In the next article we will briefly discuss online project management systems. All the artifacts that we just explained will be put into context: we'll discover where and in what format they're used.