Most of us these days develop applications and deploy them on servers, either on-premises or in the cloud. We need to plan well ahead in time as to how much server, storage and database we need. We also need to plan for deploying all the hardware and software necessary to run the application. The question here is, if is it possible to avoid all this planning? Are we looking for a new model that can handle all the underlying infrastructure deployment for us? This session is going to describe about serverless architecture and application in detail. The session will also cover on building microservices using serverless architecture. Hands-on exercise will be part of this session.

A common misinterpretation is that BDD is another way to automate the functional testing or just a synonym to Acceptance Test Driven Development (ATDD). However, it’s not correct understanding. BDD doesn’t talk about testing rather it focus on development which is driven by expected behaviour of application/system. It helps to share the understanding by examples among three amigos (BAs, Developers and Testers) and helps to explore unknown. It describes what business/end users want the system to do by talking through example behavior.

In this workshop, the actual concept of BDD is explained using case study of various real-time projects. It also covers the myths, challenges, benefits and best practices along with tools used to adopt it.

Its a simple game which helps to learn how to estimate or calculate the business value of user stories.

The intent of this game is to provide more insight on prioritization of User stories or Epics. Even though we do backlog grooming, we see that the PO is not able to bring US prioritization in the real context to the team. We can also observe that teams are not really challenging the PO about the prioritization.

This workshop is about how to involve the team more on the prioritization excercise. The PO will come out with Business value and the team will come out with the cost estimation. There will be discussions with PO and the team to understand the, what is the priority and why? As a result the the team will know why they do, what they do. This will maximize the value of their outputs.

We have used this in our work with various teams and seen it is very effective. We will talk about the examples as well.

Often we find it difficult to incorporate any changes in a software project during later phases of its development, or during post-delivery maintenance. Primary reason for this is inflexibility in design and code which makes it difficult for changes to be incorporated. This inflexibility substantially increases the cost of making changes and this metaphor has been termed as Technical Debt.
While Technical Debt cannot be eliminated completely, its burden needs to be reduced. Many agile practitioners have suggested some practices to avoid or eliminate Technical Debt.
In this session I shall discuss about a method to get relief from Technical Debt and talks about nine proven practices that a developer can follow to minimize Technical Debt. These practices help to:

• Change the coder's mindset so that they should use technical practices i.e. various refactoring techniques to reduce technical debt in code and design
• Developers to plan and manage the time to pay down the debt i.e. determine your living budget
• Take minimal technical credit in design and code

These practices have been used and found to be effective when implemented in projects which will be used as a case study.