Scrum as a Methodology is a framework of best practices and aligns with the Agile Philosophy for software development which is based on the Agile Manifesto. They both embrace change, the use of short iterative development cycles to deliver shippable products at regular intervals with constant feedback loops. They also lay emphasis on transparency and continuous improvement.
Reasons for Organizations moving away from Waterfall include its need to clearly understand the end product, create long term, linear and rigid plans that require accurate assessment, sequential execution and a Big Band approach that best suited Fixed Price Contracts.
On the contrary, what Agile Scrum brought to the table was a flexible scope of work with frequent re-prioritization based on value delivery, relative estimates and creation of self-organizing team. It is well suited for Time and Material Contracts.
Unlike the Waterfall Methodology, Scrum lays great emphasis on Product Management.
However, the disadvantage of Agile Scrum includes a loosely defined scope of work with no solid delivery dates with the probability of the final product being different from what was initial intended.
Following are 5 ways to make the Agile Scrum Methodology work for you:
1) Understand the importance of collective Estimates
Every Sprint commences with a bunch of User Stories representing Backlog Items which needs to be assigned Story Points (estimates). This is best achieved through consensus rather than a single person driving it. A discussions with team members helps one to understand the challenges in delivering a User Story and exposes issues early.
Every member of the team can participate in an estimation meeting but only the ones who are sure should estimate. A Database Admin for instants does not estimate but he could highlight how it adversely affects the database and its performance, impacts reports and other related concerns.
Agile Estimation techniques are meant to be fast and deliberately not accurate as it is fundamentally a non-value add activity. If consensus cannot be agreed upon during voting, one should pick a larger size. Coming to a consensus on the number of Story Points is important before converting them into hours.
Some collective Estimation techniques include the Bucket System, Planning Poker, Relative Mass Valuation among others.
2) Perfect your User Stories
User Stories should follow the INVEST model which stands for Independent, Negotiable, Valuable, Estimable, Small and Testable. The Small requirement here drives us to split large User Stories and is what I shall briefly touch upon.
Five basic rules one should follow to achieve it are:
a) The 80/20 principle which suggests that most of the value of a User Story comes from a small share of the functionality. Go with the split that lets you push the low-value item to the next Sprint.
b) The split that turns an 8 point story into four 2 point stories is more useful than the one that produces a 5 and a 3. It gives the Product Owner the option to prioritize better, the release of these functionalities.
c) If one usesg non-consecutive point values such as the power of 2 (1, 2, 4, 8, 16, etc.) for estimating a User Story, then break down any estimate of 16 and above into multiple User Stories. It needs to be noted that the larger the point value, the more the uncertainty associated with it.
d) Splitting based on priority requires one to start with the core functions (must haves) at the beginning, quickly deliver a minimal viable product and later, enhance the rest of the features (nice to haves) in the middle.
e) Many teams attempt to split stories by the architectural layer (ex: horizontally – UX/UI, Server Side Logic, Database etc.) as that would satisfy small but it fails to be independent and valuable. Instead, one should split it vertically which would mean that each story crosses all boundaries of the architecture but implementing only a sliver functionality each time.
Depending on the nature of the User Story, it can also be divided into various other ways such as split by process lines, procedural lines etc. which is out of our scope for discussion, given the need for brevity.
3) Get Estimates RIGHT
In Sprints, timely deliver requires good estimates. Initially, a lot of Developers go by gut feeling and make guesses. While the conservative Developers save themselves by estimating 2 to 4 times the actual effort, the optimistic ones get themselves into trouble by estimating 0.4 to 0.8 times the actual effort. Neither of this is an acceptable practice. A retrospective meeting might be a good time for Developers to look back at all their past estimates and find out their deviation factor, failing which, they will not be able to gauge how unreliable their gut feelings are.
Reasons for Developers providing inaccurate estimates include inadequately detailed User Stories and/or Functional Specs on one hand and on the other, large User Stories (ex: Epics) with complicated use and/or test cases often involving multiple user roles which have not been thought threw thoroughly.
While the Customer and the Business delegate tasks almost always suggesting it to be an easy one, the Developer should take the necessary time to assess the requirements and ask the right questions specially if the details are sketchy.
However, to deliver as anticipated, Developers need to understand that their daily workload comprises of developing new features, addressing urgent bug fixes and dealing with unplanned events. Did I forget to mention Meetings? So, the number of days for completion depends on the number of hours spent per day towards the Sprint.
Einstein once said “If we knew what we were doing, it wouldn’t be called Research” and this is quite apt for certain exploratory work where the team has no idea how long it would take to deliver the end product. In such cases, one should adopt a technique called “Spike” which involves research, investigation, exploration and prototyping. Like other User Stories, Spikes are estimated and the viability demonstrated at the end of the Iteration.
Wrong estimations lead to incomplete work and an anti-Agile pattern of carrying it over to the next iteration takes place. This isn’t a good practice. At this point, team members have to put in the extra hours and complete the Backlog Item in the current cycle and estimate better in the next. Teams failing in the first and/or second iterations is very much possible and hence, limiting their commitment initially by padding their Story Points is acceptable. When we do not have a stable team with members walking in and out, estimates of individuals and the collective velocity of the team will not be accurate.
Consistently delivering as per your estimates is required to gauge a team’s velocity. If past estimations are available, one can prevent “point inflation” and it can be used as a fair indicator of the team’s velocity.
4) Measure Performance with appropriate Metrics
As we know it, what cannot be measured, can’t be improved and hence, gauging the performance of the team through basic metrics helps and three important ones are:
a) Velocity – Defined as the number of story points completed during each Sprint, it should gradual improve in due course of time as the team stabilizes, relationships fortify, competency levels increase and work processes are optimized. If not, at the least, it should remain consistent assuming development challenges increase in due course of time but the growing competency of the Developers takes care of it. This is represented through a Sprint Burndown Chart. On a larger scale, one tracks progress through an Epic and Release Burndown. The Product Owner can then use it to forecast by when the Product Backlog will be completed. However, it needs to be noted here that comparing velocity across teams may not necessarily work because their estimation culture and attribution of Story Points could be different.
b) Lead and Cycle Time – The time taken from the point where an idea is validated and enters the Product Backlog to when it is released to the Customer is called the Lead Time. The Cycle time is a subset of it and is the time from when work starts on a Backlog Item till it is marked as “Done”. Evaluating the Cycle time is done through a Control Chart to ensure that an increasing or erratic cycle time is not observed. The end goal is to have short and consistent Cycle times regardless of the type of work undertaken (ex: new feature, technical debt etc.)
c) Number of Defects – As we know it, re-work is termed as waste in Lean and hence one needs to track the number of defects/bugs identified. Tracking Defects can commence as early as the Development phase when it is test driven and includes those identified during User Acceptance Tests and ones raised by Customers through Support tickets. This also helps us get a better understanding of the Feature vs Fix work performed by the team.
5) Manage time spent on Agile Meetings
Given the number of meetings that Scrum proposes such as the Sprint Planning, the Daily Stand Up, Sprint Review, Sprint Retrospective and Backlog Refinement, it is best that Time spent towards them is roughly 20 hours for a 4 week Sprint. These meetings can quickly go off topic and hence, it is best to use a sticky note on the Kanban board to park not urgent issues and/or new ideas.
In the next three articles, I will cover
1) Agile Team Members and their roles.
2) Discuss the adoption of best practices from various Agile Frameworks.
3) Adopting Scalable Agile Frameworks.
About the author: