Is there Sprint 0
I have seen many projects using sprint – zero as a time boxed ceremony to prepare for actual sprint. However, it is not always right to customize your process to introduce for every release. Sprint Zero can be used immediate after project kick off to ensure bringing the readiness for starting sprint activities. Also at certain cases Sprint Zero helps to streamline for other sprint activities as a terminology where the actual delivery starts from sprint 1.
But it is not appropriate to introduce sprint 0 to fill any gap in timing between releases or for any business buy in or for delivery team suitability. I have seen certain team introduced Sprint Zero immediately after a release for technical debts and improvement tasks, which in fact should be part of a sprint. And introducing it will fail the ideas of a continuous delivery.
In summary : Let us avoid sprint zero.
Sprint Demo Vs Sprint Review
Both sprint demo and sprint review sounds similar. However , I personally like to use “sprint review”. Few reasons:
- Sprint demo is a kind of submission and so lacks a collaborative approach, where development team gives a demo for completed stories to a product owner. And so it may create a chaotic state for development team members. While sprint review is more inclined towards jointly reviewing the progress of sprint.
- Sprint demo indirectly demands to demo of completed features or stories. But what will happen in a situation where no stories has completed. In such a case we can have a review on progress. This situation arises when stories when not at granular level or the unexpected complexity surfaced out during the development.
- Sprint review creates a shared ownership between development team and product management team, as both together reviews the progress of developments, and issues or risks identified.
In summary: Use sprint review terminology rather than sprint demo.
Why do we stand during Daily Stand ups call
Scrum stand up call is a recurrent meeting for a small duration of 15 minutes, where all scrum team members get together and do a short planning. This short planning starts with a quick update on what every team member has contributed towards sprint goal and what they will contribute for the day to align to it. Every team member also express any blockers they find to accomplish those tasks.
This meeting should not consume much time and should not enter to a long discussion or any brainstorming session. To be precise and to the point and to meet the goal of this meeting every team member stands up during this call.
Another reason is that team members mostly stands in a circular fashion in front the visual wall or a kanban board so that they can feel a team spirit by close to each other as a rugby team uses in a short interval. This also acts as a warm up session and connect each team members by leveraging a face to face conversation.
In summary: Give respect to daily stand up calls by attending everyday on time and having a short and precise call and of course by standing up with all team member.
For prioritization should all PBI be estimated
Product backlog items (PBI’s) are generally estimated at 3 layer.
- During product backlog prioritization
- During release plan
- During sprint plan
A high level estimation is required for prioritizing backlog items. A product owner always needs an initial estimation from a development team at least at a high level. This initial input helps a product owner to prioritize back log items by trading off between team’s estimation and the business value ( return on invest – $ value ). Team’s estimation of work includes the level dependency and their concern on technical complexity at current capacity and infrastructure set up and the volume of work it demands to complete the task. This is a continuous process where team reevaluate each feature or work items (stories) on every product backlog grooming session.
In summary: Yes PBI’s should be estimated for a better prioritization.
Is there any recommendation on Backlog Size
Backlog size can not be fixed and closely depends on the product features, technical debts, new improvement notes. Even a great product owner can not decide the expected size of a product backlog. However, the balance is necessary between the increasing size of a backlog and the cleaning the backlog in terms of minimizing work in progress stories/features. We can define the work in progress limit as that will help team to focus on completing tasks necessary to close those features to ensure balancing between load and delivery.
Backlog size changes over a period of time. During starting of a project it grows exponentially and shrinks towards the closure of the development of product. The stack grows day by day as new features and stories are added up.
Size also depends on the velocity of development team. More the velocity of development team the sooner to clean it.
However, it is also equally important to clean up the backlog with all unwanted and dead features. And that is why great product owners owns a great product backlog.
How will upfront estimate be right without details
Estimation is not always perfect until a high level of clarity and understanding is achieved. And so the relative estimation works well till the team reaches a high level of product understanding maturity.
An upfront estimation at high level can be more appropriate for that time and get refined as soon it explores more into deep. As it is always better to estimate close to proximity rather than waiting for certain time to get a better clarity and then estimate with a clear visibility. Due to high level of uncertainties and ever changing market demands predictability lowers down.
In agile framework estimation is done at various layer as on onion planning. It might be during backlog grooming and prioritization, during sketching release plan and during sprint planning too.
In summary: Upfront estimation can not be right always but it fulfills the future estimation and can be input for a revised one. So use relative estimation in terms of relative weight or story points compared to base line or past experience. Remember estimation is not always perfect until it get revised time to time with more detailed information. So do not wait for detail information to estimate; estimate with what supporting information you have right now and proceed.
Does scrum recommend dev practices like TDD-BDD etc.
Scrum is a light weight framework which prescribes certain number of roles, ceremonies and artifacts necessary for a successful product development aligning towards agile manifesto principles and mostly used in IT development sector.
While test driven development and behavior driven development are certain technical practices which support scrum and agile philosophy. Any agile practices as well scrum follows an incremental and iterative way of delivery. And so both TDD and BDD supports in enabling agile principles by smoothing it’s philosophy.
In summary: Scrum does not directly recommend to use TDD/ATDD/BDD , but yes all these technical practices supports scrum philosophy. Also it depends on an organization as well the development team to decide which way of developing application is suitable for them for maximum benefits.
Why it is recommended to have 15 min for daily stand ups
It is recommended to use a 15 minute time box for a daily stand up. The reason behind is to make the daily stand up call short so that it should not create an overhead for the team. This meeting should not end with a long explanation, technical clarification or any sort of debate on issues and dependencies. One probable reason is that it takes approximate 2 minute for a team member to share his last day activities and plan for today’s as well any roadblocks to achieve this. Considering this it should not take more than 15 minute for an ideal scrum team of 7-8 team member. This also allows to be more focused during the call.
However, it is not a hard rule to stick only to 15 min, but yes ( +/- ) 5 / 10 min can be adjusted depending on your team size the complexity of project as well. But it should be time boxed. Whatever short time suitable for your team , stick to it and plan to finish within that time box. The reason behind is that, it will create an uniformity and a rhythm within the development team.
What is the ideal productive hour per day for a team member
Productivity depend on various factors. 3 important factors are:
- Motivational Factors (Internal & External)
- Hygienic factors
- Organizational environmental factors
- Past similar experience
All the above factors differs from person to person, team to team as well from an organization to another. So it will be very difficult to predict the actual productive hour for an individual. However most agile projects uses ideal productive hour rather than actual productive hour. A typical day for any development team includes attending scrum meetings, technical know how session, brain storming, coordinating with various stakeholders, discussion with team members as well attending personal calls. So it is advisable to use ideal productive hour. Productivity will be high when the technical debt is low, quality is high on every deliverable to minimize rework. In such a case the ideal productive hour should fall in a range between 60% – 80% of used hour for each team member.
This estimation helps in establishing a sustainable capacity and lowers down any unnecessary pressure over the development team and so can easily manage a buffer capacity which can be used for any last moment challenges.
- How it differs Scrum in Product vs Scrum in Service industries
- Is scrum master or Dev team member represents in Scrum of Scrum
- Can a team have BA’s and PO
- How to address half done stories
- How to bring agile in a support team
- How to bring a high productivity team
- Is documentation is not needed in Agile
- How to adopt agile in a fixed bid project
- How do we bring 0% error in our estimation
- What is the growth for a scrum master role
- How to improve productivity of a team member
- How do we do requirement mapping and tracking
- How to improve the productivity during initial sprints
- How to enable empowered team to speak up in Agile
- How important is readiness of environments and infrastructure
- Is POC is better for a complex project than detailing requirements in agile
- Is Agile audit friendly. e.g. CMMI requires empirical estimate not Story points
- Scrum in a multiple deliveries from multiple teams with a clear dependency in the same sprint