Home / Demandware / Best practices in Agile development in ecommerce implementation
Best practices in Agile development in ecommerce implementation

Best practices in Agile development in ecommerce implementation

All retailers and eCommerce implementers around the world are accepting that the Agile is best suited for developing and supporting eCommerce websites. The reasons are obvious:

Speed: The retail industry is going through unprecedented change and every day innovations are announced to make e-Retailing better, effective and more profitable. No retailer can afford to lack behind and hence delivery / deployment has to be rapid.

Flexibility: Growing the business means reacting to changing environments and circumstances. Business needs change all the time, especially in eCommerce, which requires a versatile strategy that can adapt to evolving or changing business needs. Directors can change their mind about a particular element for development, or go in an entirely new direction. Hence, flexibility is required all the time.

Long collaboration: eCommerce journey can never be over, running an online business have similar journey just like a physical retail store which you have to keep running, keep making changes; and every time, you have to get more profit than the last season. Domain knowledge and tactics have to be effectively converted and applied on storefronts. For this, a business needs an efficient implementer team which works closely with them.

Following Agile can provide speed, flexibility and long term collaboration with great level of quality and customer satisfaction. Here are few pointers which need to be considered which can make an eCommerce implementation successful while working with Agile:

 

scrum team

“Do it Right” from where it originates: Many teams fail to implement stories or manage to deliver it with poor quality due to requirements are not clear. Scrum team raising questions while implementing or testing the story adds huge amount of time and (re)work. The role of Scrum master is always very crucial to facilitate quality conversations on requirements happening some days before the sprint starts. In an ideal world, Product owner and Scrum master should be one sprint ahead of the scrum team in terms of requirements gathering and designing. Hence, pushing business owners to get all the dependencies resolved like getting the PSDs for front end development or documentation / credentials required for 3rd party integration.

Particularly in eCommerce projects, Stories can be divided into categories like Front end, Back end, Third party integrations etc. This helps to plan the sprint. In case of a complex 3rd party integration which requires development on front end, back end and also has some external dependencies, best is to create an EPIC to track all the deliverables, and then stories should be written in logical order keeping in mind the dependencies, and then divided by their nature of work (Frontend or backend).

Size of the story is the important success factor. Granular stories deliver the best. Smaller stories have many advantages like, less ambiguities, faster sprint velocity and work balance between developers and QA. If the stories are bigger, QA are going to be out of capacity at the end of sprint and also the time for UAT will squeeze.

Estimating stories in hours works best when the team is still new to Agile, team can collectively decide when to move to story points later on. Also, it is advisable to take the estimation from individual team member who is actually going to work on it rather than averaging the estimates. “Average Estimate” is nobody’s estimate. It brings ownership in developer and QA if the estimations have come from them. Scrum master can challenge those if they are too high or vice versa.

In general, the Story should follow the “INVEST” rule. INVEST means Independent, Negotiable, Valuable, Estimable, Small, Testable.

A sample story format for eCommerce projects can be:

**********************

AS A Product owner / User / Retailer / Merchandiser, I WANT TO <do something> SO THAT <objective is achieved.>

Acceptance Criteria: <Bullet points>

Affects Components / Storefronts (Sites): <Impact Analysis helps QA>

**********************

Size of the sprint: There is no strict rule on the size of the sprint. In theory, it is either two week sprint or a month long sprint. However, 2 week sprint can be stressful at times and also it results into more frequent scrum ceremonies. On the other hand for a month long sprint, Client will hardly agree on having to wait for a month to get something delivered. That is why, it is better to have a middle way out, a three week sprint. It keeps the delivery faster with giving required breathing space to everybody.

Some one-liners / Golden rules:

  • After story grooming, there should be no open questions on any story.
  • After Sprint planning, nothing goes in and nothing goes out of the sprint. If “something” has to come in, “something more” has to go out.
  • Sprint cannot start until all the stories are estimated.
  • Nothing is obvious, if something is not written in story, it will not be developed and tested.
  • Only after the demo, client should start UAT.

Adapting to agile also means that there is more engagement with client, which may result in generating new business.

With agile, the lead time (Time between Contract sign to GO live) has reduced and experts are still finding ways how to reduce it further. Major eCommerce Platforms like Hybris and Demandware are capable of launching new ecommerce sites in 3 to 4 months. Not only on-boarding but also in-life projects are successfully executed and are more profitable.

 

About Nirav Belani

Author Image
Nirav is a technical lead at Adapty. He has more than 7 years of experience overall and has been practicing Agile - Scrum in eCommerce projects for more than 3 years. He has led the Go-live as well as Support Projects in eCommerce.

Comments are closed.

Scroll To Top