UI block – Epic 31. Information sections

UI block – Epic 32. Forms

UI block – Epic 33. Content sections

UI block – Epic 34. Spotlight

Epic 21. IMS. Remove the bag

Epic 22. Products

Saclab Company Information

General info

Implement a Blurred our text block on the Saclab Journal article (Post) such as https://saclab.com/chanel-chevron-or-diamond-quilting/ for the purpose of giving a sneak peak.

User story

As a journalist (author)

I want to give the reader a sneak peak of the journal article/ report, so if they want to read the whole thing, they need to download it or get in touch

Visual design

Figma: https://www.figma.com/file/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?type=design&node-id=3967%3A1847&mode=design&t=wyWSdsA7aSqIR2GH-1

	Acceptance criteria
01	Given: Article blog page When: set up block as “blurred paragraph” Thư Phan what do you think about this? or it has to be automatically for all paragraphs? Then: see the paragraph in the article with blurred text The height of the blur effect should be 50% the height of the text while it should have the same width
02	This block should have all the functions as the “paragraph” block, only it has a blurred-out effect at the end of the text.

General info

Implement a user email input section on the Saclab Journal article (Post) such as https://saclab.com/chanel-chevron-or-diamond-quilting/ for the purpose of report (PDF) delivery.

User story

As a website user

I want to subscribe and download the full Luxury Brief while I see the articles in the Journal

So that helps to get useful information

Figma design

https://www.figma.com/file/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?type=design&node-id=3967%3A1847&mode=design&t=dM4SiuqUr2HxA81H-1

Email template:

https://us12.admin.mailchimp.com/templates/edit?id=10075426

	Acceptance criteria
01	Given: page https://saclab.com/chanel-chevron-or-diamond-quilting/ When: scroll to the form (can be placed in any part of the article) AND input email adress AND click button “Send“ Then: see “successful” popup AND triggers the action that a PDF file specified by admin is sent to the inputed email address Thư Phan do we have to change this form on a page? https://prnt.sc/b2DL053KnUqI	Email Input Field: Integrate a field where users can input their email address. A “download” (send) button: this button triggers the action that a PDF file specified by admin is sent to the inputed email address.
02	Email address should be validated (same rules as when signing in for http://saclab.com ) Warning text: Eng: Invalid email address, please try again Fr: Adresse email non valide, veuillez réessayer De: Ungültige E-Mail Adresse, bitte versuchen Sie es erneut
03	Given: Page and Form on it When: scroll to the form and see tick box under the button Then: box should be pre-ticked, allowing users the option to untick it if they do not wish to subscribe If this tick box remains ticked: add the email address to our Mailchim SACLAB Newsletter Audience Text: "Subscribe to Saclab News and Updates." => admin should be able to change this text
04	Include a disclaimer text: “By registering I accept the data privacy policy and the indications specified on data handling.” => allow admin to change this text if they want to, add link should also be possible (as seen in “privacy policy”)
05	Admin should be able to change ALL the text and CTA in this block
06	The email addresses should be collected and saved on Mailchimp
07	Admin should be able to upload/ choose the pdf that will be downloaded

General info

On the Post (journal article), add a “Published on” or “Published on [Date] / Updated on [Date]” that show the published and/ or updated date.

User story

As a website user

I want to see the published and updated date on the article page

So that helps to understand how old the article

SCLB-465

Desktop design:

For when the article is published (with no revisions): https://www.figma.com/file/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?type=design&node-id=3956%3A1185&mode=design&t=mycDJnOYEthZBrRo-1

For when the article is updated: https://www.figma.com/file/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?type=design&node-id=3956%3A932&mode=design&t=mycDJnOYEthZBrRo-1

Mobile design:

For when the article is published (with no revisions): https://www.figma.com/file/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?type=design&node-id=3956%3A1726&mode=design&t=mycDJnOYEthZBrRo-1

For when the article is updated: https://www.figma.com/file/6KT0tZfJw3u7R8b5pCH8vw/Saclab-Team-Library?type=design&node-id=3956%3A1438&mode=design&t=mycDJnOYEthZBrRo-1

	Acceptance Criteria
01	Given: blogs section in the admin panel When: create new blog article AND press publish button Then: see on the front-end part of the site new article with the published date Text: published on mar 12 2023 Format: 12 Mar 2023
02	Given: blogs section in the admin panel When: change some blog text and media AND press update button Then: see on the front-end part of the site updated article with the published and updated date Text: published on mar 12 2023 / updated on DEC 12 2023 Format: 12 Mar 2023
03	No extra work from admin should be required

User story

As an admin on saclab.com
I want to replace the bags in the order – and sync to Airtable
So that helps to change bags in the order

26.12.2023 – IMS (sprint 1)

What can be improved:

1. Start making user/scope documentation (confluence) and developer documentation.

2. Divide the work into sprints with a fixed scope and period. Estimate tasks before the start of the sprint, all new requests go to the next sprint or replace current tasks (current tasks with lower priority are postponed to the next sprint).

3. Add/plan the stages of bug-fixing and UAT. UAT after our test, not in parallel.

Communication

• Response Time on Slack: 3 working hours.

• Response Time on Email: 2 working days.

• Let the client about the increased estimation of the task in advance (before the task is tracked more than expected).

• Integrate Jira notifications into Slack to reduce communications in Slack.

• It takes the developer no more than 1 hour of time to estimate the task. If more time is needed, it should be agreed with the client.

• NEW If a bug fix requires more than 1 hour, the developer and Project Manager must align on the estimated time before proceeding. Any additional hour of work should be approved in advance.

• Always ask/ inform the Saclab team before transferring anything.

• Never transfer on Friday unless the Saclab team asks you to do so.

Tracking tasks

• track communication into specific tasks.

• track scrum and other general meetings into specific tasks. Track time of team collaboration in specific tasks.

Workflow JIRA

1. Create task via JIRA tickets and confluence into PRODUCT BACKLOG (Product Owner). Create tasks using the name Epics and Stories in the confluence. Attach the confluence documentation to JIRA tickets.

2. Assign the task to a Project manager in column Estimation when task is ready to estimate with priority (PO). Let the PM know if you want this task added to the current sprint upcoming release.

3. Estimate task (PM + Dev team).

4. Add deadline to the task to SPRINT BACKLOG (Product Owner + PM).

5. Move task into TO DO phase (PM).

6. Move task into IN PROGRESS phase (Dev team).

7. Move task into CODE REVIEW phase with a link to Pull Request and comment if further clarification is needed for QA (Dev team).
   OR Move task into READY TO MERGE IN MASTER WITHOUT QA phase and assign PO (Dev team).

8. Move task into READY FOR QA phase (Dev team, code reviewer).

9. Move task into QA IN PROGRESS phase (QA).

10. Move task into TO DO phase if something is wrong, with comment (QA).

11. Move task into QA APPROVED phase and assign the PO if everything works well (QA).

12. Move task into READY TO MERGE phase and assign the Dev member (PO).

13. Move task into MERGED TO LIVE phase and assign QA (Dev team).

14. Move task into DONE phase and assign PO (QA).

15. Reopen the task from DONE to BACKLOG if needed (PO).

Release processes (SCRUM)

• Separate product backlog into 2-week sprints.

• Start sprints on Wednesdays. Finish on Tuesdays.

• Estimate tasks before starting the sprint (Refinement meeting every Monday).

• Calculate capacity and velocity for the current team.

• Have the plan and estimated tasks at least for the next 2 sprints.

• New requests can be planned for the next sprint or replace current tasks in the current sprint with lower priority. Current tasks from the current sprint will be moved to the next sprint. In case nothing moves – a decision is made to increase the length of the sprint or increase the team with approval for additional budget.

• Each change in the task’s descriptions (user stories, acceptance criteria) has to be reestimated.

• After deployment to production, the QA team has to check the checklist of all features. In case if will be found a critical bug the code need to revert, then fix it and make a new pull request. In case if revert is impossible or we can make a hotfix very fast – revert is not needed.

• Demo meetings in the end of the sprint on Tuesday (STAGE) to get approval to update the LIVE.

Release processes (KANBAN)

• Estimate tasks before starting work.

• Calculate capacity and velocity for the current team.

• Each change in the task’s descriptions (user stories, acceptance criteria) has to be reestimated.

• After deployment to production, the QA team has to check the checklist of all features. In case if will be found a critical bug the code need to revert, then fix it and make a new pull request. In case if revert is impossible or we can make a hotfix very fast – revert is not needed.

• Demo meetings in the end of the sprint on Tuesday (STAGE) to get approval to update the LIVE.

• In case we have tickets ready for merge, we are preparing them to release on Tuesday or Thursday. Befor merge in production we need to have final code review from Tech lead.

NEW! Bug reporting and charging

1. [Hotfix+] – reproduction of the bug on live, the fix of which is paid for by the client.
   Identification:
   – there is no scenario or criteria that describes in the initial scope;
   – the bug is not related to the scope of the current or previous sprint.

2. [Hotfix-] – reproduction of the bug on live, the fix of which is not paid for by the client.
   Identification:
   – there is a described scenario or criteria that is not work;
   – the bug is related to the scope of the current or previous sprint.

3. If the time spent on the task and fixing the problem [Hotfix-] is within the estimated time of the original task, the time spent on the task and solving the hotfix is paid in full.

4. If the found bug [Hotfix-] goes beyond the estimate, then everything that is tracked above the task estimate is not paid by the client.

Hotfix description:

1. Ticket type. Set the type of ticket – bug.

2. Ticket name. Use text [Bug] for the [Hotfix-] at the beginning of the ticket name (it will be easier to separate hotfixes in tracker report).

3. Link to the scope. Add related link to the documentation or another ticket, which describes the initial scope with the scenario and criteria.

4. Description in the bug report. Provide information about which scenario or criteria was not met (criteria number or item of the initial task). Add Actual result with steps to reproduce, video or screenshot and Expected result.

GIT Flow (not finished description)

1. Get the code from the master.

2. Develop features.

3. Deploy to STAGE using CI/CD settings.

4. Collect all the features for the sprint and deploy them all together to the LIVE.

5. Hotfix has to be deployed to Stage env, after developing merge to master.

User story:

As an admin user of Airtable or WooCommerce
I want to remove a product from sale so the product becomes “Sold out” on the website and send information to the seller (when applicable)
So that helps to close the product from sale on the site and notify the seller

	Acceptance criteria
01	Given: on WooCommerce Where: page of created product on WooCom e.i. https://saclab.com/wp-admin/post.php?post=79379&action=edit When: scroll to “Quantity” and change the quantity to 0
02	Given: page of created product on AirTable e.i https://airtable.com/login?continue=%2FappRQ91IjkyM2wP3u%2Ftbl5PXxzl5h9KIIBi%2Fviw6GPAq9ChJvn1PB%2FrecQwfOWVpFciyrLW%3Fblocks%3Dhide&redirectSource=liveapp When: scroll to “Quantity” and change the quantity to 0
03	Given: create a new product either on AirT OR WooC When: set the Quantity as ZERO
	Then: WooCommerce: 1. Product status changes to “Out of Stock” + Removed on [Dated + time] 2. On the front-end: product has status “Sold out”
	Then: Hubspot Deal moved to "Removed from sale"
	Then: on AirTable Product’s status is changed to “Removed from sale” Add field: removed on [DATE] “Removed by”: = name of the admin who changed the product quantity to 0 "Email sent" field shows the name of the email + sent [DATE] option to resend the email to the seller
	Then: Automatic Email to the seller: Your |BNAME| has been removed from http://saclab.com En: https://us12.admin.mailchimp.com/templates/edit?id=10053137 DE: https://us12.admin.mailchimp.com/templates/editor?id=10053141
	Then: Automatic Email to admin: The |BNAME| has been removed from shop https://us12.admin.mailchimp.com/templates/editor?id=10053121