Roles and Responsibilities during Scrum Ceremonies

Ceremonies	Scrum Master	Product Owner	Development Team
Release Planning	Make sure Release plan ends with List of PBI, number of sprints.	Why we do this release, stakeholders expectation on this release, timeline, PBIs for the release.	Provides team velocity to consider while release planning
Product Backlog Refinement	Confirm all questions of Dev team are cleared by Product Owner PBI are enough for next 2 sprint as per team velocity	Introduces the PBI and explain Definition of Done, any specific Voice of Customer related to the PBI, rank of the PBI, Clear all doubts, manages PBI splits.	Understand PBI and Definition of done and ask as much question to Product Owner to establish acceptance criteria and uncover potential technical challenges.
Sprint Planning	Make sure Sprint plan ends on time. Post a poster on burndown chart for team update. Quote Team capacity, indicate velocity.	Make sure the PBIs taken by Dev team are in line with produce release plan; Understands and decide on dependent PBIs, Conclude Sprint Goal.	Confirms the team planned capacity.  Indicate technical dependencies, Issues in Definition of Done, choose PBIs for the sprint, manage themselves on list of task and confirms task are leading to sprint goal.  Commit on the PBI.
Daily Scrum	Update chart, List down Impediments. Before Review: Remind Review preparedness to Dev Team.	Monitor scope. Help team to get further clarity on PBI	Update the progress to team. Plan for today and highlight impediments
Sprint Review	Send invite to all stake holders in advance.	Accept or reject sprint outcome	Show outcome of latest sprint and answer questions to the Stakeholders.
Sprint Retrospection	Read feedback, impediments faced, Action & results observations, Share Product Owner feedback, how much Scrum followed, Read improvements planned and actual from last Retrospection.	Not required but can join if team looking for help.	Open discussion towards improving the efficiency of the team; identify key problems faced, review last improvement action & Result.  Append new actions.

How CSD can help in getting CSP credential faster?

How CSD can help in getting CSP credential faster?

If you are CSM/CSPO then you are already eligible for 16 and attending 3 days CSD engineering training will give additional 24 SEUs so total category “B” SEUs is 40 and remaining 30 can be easily earn either through category C, D, E of F. Like if you attend 2 days PMI-ACP training then you will get additional 15 SEUs. 15 SEUs can be claim through reading 1 or 2 Agile and Scrum books. 

If you are not CSM/CSPO but having 36 months of working experience in agile/scrum environment then attending CSD will give you 40 SEUs. You can attend additional 2 days training on Scrum/Agile related topics provided by REP like Leanpitch to get 16 SEUs so total category “B” SEUs will be 56 and remaining can be easily earn either through category C, D, E of F. Like if you attend 2 days PMI-ACP training then you will get additional 15 SEUs and 15 SEUs can be claim through attending User Group's event. Play Scrum and Agile Software Developers Network keeps organizing such events every month.

Certified Scrum Developer (CSD) Training is available in Bangalore, Chennai, Pune, Hyderabad and Delhi.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (TDD), Behavior Driven Development (BDD), Cucumber, Selenium, Jira Agile, Scrum, Jenkins, Scrum Master, Scrum Developer, Product owner, agile estimation and planning, writing user stories etc.

How to earn 70 SEUs for CSP

How to earn 70 SEUs for CSP

Scrum alliance has 6 different categories through which you can earn SEUs and these categories also have some limitation.

Category “A”/Scrum Alliance Scrum Gathering – You can earn maximum 45 SEUs in this category. One SEU per hour of participation in scrum alliance global, regional or user group scrum gatherings as well as Scrum alliance affiliated user group.

You can earn these SEUs either through presenting, coaching and attending sessions. For example you can earn SEUs through attending Regional Scrum Gathering India event or event through user group like Play Scrum and Agile Software Developers Network.  

Scrum Alliance Guideline - 
Attended Global Scrum Alliance Gathering
Attended Regional Scrum Alliance Gathering
Attended Scrum Alliance User Group Activity
Attended Scrum Alliance-Sponsored Event
Attended Scrum Coaching Retreat 
Attended Scrum Coaching Retreat Pre-Workshop

Category “B”/Scrum Alliance Course – There is no limit for this category. CSM and CSPO certification is eligible for 16 SEUs, CSD is eligible for 24 SEUs. You can also earn through attending training course provided by REP or CST. Training by Scrum Alliance CST and REP must follow below guidelines.

If you are CSM or CSPO then attend 3 days CSD engineering training to get additional 24 SEUs. You not only get 24 additional SEUs but also additional certificate - CSD. 

You can also earn additional SEUs through attending various training deliver by CST and REP like Leanpitch. These training includes TDD, BDD, Writing USer Stories, Scaling Scrum and Continuous Integration.

Scrum Alliance Guideline - 

Received CSM Training

Received CSPO Training

Received CSD Training

Received Training from a CST (including video training)

Received Training from a REP (only approved courses and trainers)

Received Coaching by a CSC

Category “C”/Outside Events – Up to 15 SEUs in this category through attending Scrum conferences like AgileNCR or training on agile topics provided by someone who is not a REP or CST. Attending 2 days PMI-ACP training will help you in getting 15 SEUs.

Category “D”/Volunteer Service - Up to 15 SEUs may be earned by providing non-compensated, Scrum professional services to an organization or group other than your employer. You can earn these SEUs even through helping REP or CST in organizing and delivering seminars.

Category “E”/Asynchronous Learning – Up to 15 SEUs may be earned through various independent learning activities, such as preparing presentations, authoring relevant books or reading some books deeply and then describe benefits.

Category “F”/ Synchronous Learning – Up to 15 SEUs may be earned through a variety of other learning activities that doesn't fit in above category like working as co-trainer with more experience trainer.

How to earn SEU for CSP. How to become CSP.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (TDD), Behavior Driven Development (BDD), Cucumber, Selenium, Jira Agile, Scrum, Jenkins, Scrum Master, Scrum Developer, Product owner, agile estimation and planning, writing user stories et

Agile engineering is not just important but essential for higher ROI

Agile has become popular within software industries not only in product development organizations but also within software service organizations. There are many factors that driving this change including time to market, continuous change in requirement, increase productivity and better accountability etc. 

Agile get defined by Agile Manifesto and Agile Manifesto consists four values and twelve principles. It is easy to remember four values but not always easy to implement all principles because it's required engineering practices in place to implement. This is one the reason for higher demand for agile engineering coaches to provide supports to adopt these technical practices like TDD, BDD, ATDD, CI/CD, DevOps and Agile Architecture & Design etc. Nowadays all leading scrum certification authorities is promoting these practices through their certifications program like CSD (certified Scrum Developer) and PSD (Professional Scrum Developer).

Below is mapping of engineering practices against some of the agile principles to visualize how these become important.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Delivering product frequently with new features looks easy during initial stage and also when team is small but issues start appearing after few deliveries or when new team get added to work on same product. These issues are mainly related to integration of code and ensuring newly added code has no impact on already released features. Opting for continuous integration practice and using tools like Jenkins, CruiseControl, Hudson, TFS etc can resolve these issues.

Business people and developers must work together daily throughout the project. Working together mean whole team available to each other and help each other whenever needed. But it would be good if business people write acceptance test cases in way that enable developers to write code. Automating acceptance criteria using any BDD/ATDD tools like cucumber, SpecFlow, Nbehave, Behat or Fitnesse will give confidence to business people because implementation of new stories can be verified immediately. 

Continuous attention to technical excellence and good design enhances agility. Agile architecture and design is a need of hour. Having big design up front (DBUF) is not good practice and team moving towards emergent design. Ideally the team that code the system also design the system and focus should be on build a design that can possibly work. If development team is also designing the software then team focus is not only meeting the requirement but also on how to enhance design. Following SOLID design principles and coding through TDD will help in technical excellence.

Simplicity–the art of maximizing the amount of work not done–is essential. Agile architecture and design also talks about YAGNI (You aren’t gonna need it) and KISS (Keep it simple, stupid) principles but having BDUF is violation of these principles. Purpose is simple, Code as much as needed to meet the requirement and nothing more. Test First approach helps in writing less code and only that much needed to pass test.

The best architectures, requirements, and designs emerge from self-organizing teams. The teams that code the system also design the system because team is empowered to define, develop and deliver software. Build the simplest architecture that can possibly work. If non-functional requirement and prototype of system is not sufficient to take design decision then better to code to understand potential impact of the design. TDD and Refactoring helps is producing better design because design get tested during coding.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (#TDD), Behavior Driven Development (#BDD), Cucumber, #Selenium, #JiraAgile, S#crum, #Jenkins, #ScrumMaster, #ScrumDeveloper, #ProductOwner, agile estimation and planning, writing user stories etc.

Why agile adoption fails within organization?

I have been reviewing agile adoption process for product company, service company and also product company where vendor is engaged in developing/supporting product either following Fixed Price or Time & Material. My job is to observe why team fails to deliver product on time while following agile (Scrum) methodology and recommend and coach team to deliver working product. 

Below is my observations based on process review, interaction with management, vendors and team members. I attend all ceremonies like daily scrum, sprint planning, sprint review and retrospective to understand gap in adoption. Also review tools that team is using before coming up with any recommendation. 

Adoption of Agile without any formal training – Team has not gone through any formal training and have no or little knowledge about agile project management. Just following management instruction to deliver project using agile.

Individual and Collaboration vs Command and Control – Agile values and principles is completely misunderstood by team. Manager/leads still driving team rather than team taking own decision based on inspect and adapt. This leads to dissatisfied team and team member not motivated. 

Fixed price contract and agile – Vendor says fixed price and agile can’t go together and vendor consider fixed price contract is top most impediment. Vendor’s management team is passing this message down to team as well that leads to misunderstanding about agile in fixed price project.

Sprint duration not consistent – Sprint duration is not consistent so velocity can’t be calculated that leads to unpredictable delivery timeline.

Definition of Done (DOD) and Acceptance criteria not defined for sprint – Team is iterating sprint by sprint but product not. There is no clarity about DOD and acceptance criteria and team itself testing product and logging defects.

Project management tools not properly configured/utilized – Team is using tools like Jira, Rally or RTC and some them even MPP but these tools not helping team in release prediction. These tools are also not in sync with other tools like requirement management, bug tracking etc and not getting updated regularly so not helpful.

Continuous Integration missing – CI tool is available but not configured and team is not configuring CI that leads to resource waste towards the end of project. Team spend many hours in every sprint to fix only integration issues towards the end of development.

Team structure – Team doesn't have proper scrum recommended structure. Lead playing role of scrum master, technical people playing role of product owner. Scrum master and product owner role is completely misunderstood. Team is also not cross functional because sprint runs only for developers and testers still follow waterfall approach

.

Agile metrics not implemented - Team doesn't have any defined metrics like burn-down chart, team velocity, release burn-down etc. Team velocity is known in absence of metrics. 

Product Backlog is not managed and groomed properly – Team not working on breaking big feature/change request/defects into a small and manageable stories. One big features getting completed in multiple sprints.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (TDD), Behavior Driven Development (BDD), Cucumber, Selenium, Jira Agile, Scrum, Jenkins, Scrum Master, Scrum Developer, Product owner, agile estimation and planning, writing user stories etc.

Simple but powerful agile metrics to monitor progress

Sprint burn-down - Scrum teams organize development into time-boxed sprints. At the outset of the sprint, the team forecasts how much work they can complete during a sprint. A sprint burn-down report then tracks the completion of work throughout the sprint. 



Cumulative Flow Diagram – This will help Kanban team especially for team working outside scrum team to limit work in progress (WIP). Limiting WIP will help team to focus on assignment that has been already initiated.




Release burn-down - Epic and release (or version) burn-down charts track the progress of development over a larger body of work than the sprint burn-down, and guide development for both scrum and Kanban teams. Since a sprint (for scrum teams) may contain work from several epics and versions, it's important to track both the progress of individual sprints as well as epics and versions.

Velocity - Velocity is the average amount of work a scrum team completes during a sprint, measured in either story points or hours, and is very useful for forecasting. The product owner can use velocity to predict how quickly a team can work through the backlog, because the report tracks the 


Defect ratio – This will help to establish number of defects per story/feature/epic based on defect logged in by business/product owner.

Cycle time - Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for Kanban teams, scrum teams can benefit from optimized cycle time as well.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (TDD), Behavior Driven Development (BDD), Cucumber, Selenium, Jira Agile, Scrum, Jenkins, Scrum Master, Scrum Developer, Product owner, agile estimation and planning, writing user stories etc.

Why acceptance criteria for every story is important to deliver project successfully?

What is acceptance criteria?

Acceptance criteria are documented requirements for every story and product owner

validate every completed story against these criteria. Team consider these criteria as checkpoints while developing software and story is considered done when team meets all criteria. Lack of clarity on acceptance criteria can leads to poor quality and delay in development.

Acceptance criteria must includes functional and as well as non-functional requirement. Functional requirements include exact business processes, user types, boundary limit and validations. Non-functional requirements includes authentication, authorization, speed, security and performance.  

Who will decide and write all acceptance criteria?

Ideally customer (product owner) should write acceptance criteria because product owner know about requirement. But does product owner also understand about non-functional requirement? If yes, can team deliver all non-functional requirements? Considering all this, its better that product owner writes functional acceptance criteria  and further refines them during backlog grooming and sprint planning where team collaborates as well.

What is format for acceptance criteria?

There is no such format for writing acceptance criteria but if team is planning to follow Acceptance Test Driven Development (ATDD) or Behavior Driven Development (BDD) then Given, When and Then is very popular format.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (TDD), Behavior Driven Development (BDD), Cucumber, Selenium, Jira Agile, Scrum, Jenkins, Scrum Master, Scrum Developer, Product owner, agile estimation and planning, writing user stories etc.