One of the many new practices for organizations going through agile transformation is the move from requirement documents to user stories. I’m quoting from Mike Cohn *:
„User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a < type of user >, I want < some goal > so that < some reason >.“
In the classical approach, there is a requirement document that has been agreed by development and business groups after multiple time-consuming iterations. Even if both parties agree on a document after significant time and start developing the new feature, chances are part of the original scope gets obsolete or changes and things need to be reiterated and perhaps portion of the development efforts have been wasted. This approach is obviously not suitable particularly for time-critical projects. On the other hand, user stories are mutually understandable both for customers and developers and increase the communications between team members and stakeholders. User stories also allow the development team do the practical planning. As Roman Pinchler nicely puts it **:
„User stories are not about documenting requirements; they want to enable you to move fast and develop software as quickly as possible;not to impose any overhead.“
„„Working software over comprehensive documentation““ weiterlesen
Scrum framework doesn’t mention about how the software is developed i.e. which development techniques have been used. It lets the team to decide which techniques and practices will be used. I think it’s a good idea to share the practices we benefit as a Scrum team thanks to the leadership of the Scrum Master. (A tailor-made adaptation of XP practices)
Pair Programming: All production code is written by two people at one screen/keyboard/mouse. This helps us to ship software with superior quality, less bugs, less iteration and as a result greater efficiency.
Test Driven Development: TDD is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests. Chances are the test coverage percentage of our software stack decreases due to other priorities. In any case, we focus to keep it above a certain threshold.
Unit testing: It's a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. Unit testing is key for the team to level less buggy software.
Continuous Integration: New code is integrated with the current system after no more than a few hours. When integrating, the system is built from scratch and all tests must pass or changes are discarded. This eliminates manual work and saves time and efforts.
Refactoring: The design of the system is evolved through transformations of the existing design that keep all the tests running. In the lack of refactoring, the quality of software decreases and the probability of major bugs increases.
One of key definitions of the Scrum framework is „Definition of Done“(DoD). In order to be able to decide when an activity from the Sprint Backlog is completed, the Definition of Done (DoD) is used. This bring all the team members to the same level of understanding about the conditions when a task is completed. The definition of done for our team is as follows:
Any issue in the Sprint Backlog is considered to be „Done“ if the analysis, development and validation stages have been completed successfully and the acceptance criteria has been met. The deployment is not a prerequisite for the issue to be considered as „Done“.
„From Continous Delivery to Continous Deployment“ weiterlesen
One of key metrics of a Scrum team is Velocity. Even though it’s not mentioned in the Scrum guide, it is still very useful for the Product Owner while planning the Scope of the next Sprint and defining a concrete Sprint Goal.
As the name implies Velocity (consider the team as a vehicle) is a metric calculated by averaging the total amount of Story Points completed over the number of Sprints within the same period. In practice, the velocity of the teams gets stabilized after a certain number Sprints are left behind. As the number of Sprints increases, the velocity starts oscillating in a regular rhythm.
„Velocity : Key metric to secure an effective Sprint Planning“ weiterlesen
One of the key responsibilities of a Product Owner is looking after the backlog and building and maintaining the Product Roadmap. The Roadmap is a great tool that provides a visibility regarding the Scrum team’s work and to materialize where the team is headed to. It’s a good practice to communicate the up-to-date Roadmap with the shareholders often in order to let them know which new features and bugfixes are planned over the coming weeks and months and to notify if there is a recent change on the planning.
We are running 2 weeks-long Sprints. At the end of the Sprint Review session, as the PO, I’m presenting the PBIs (Product Backlog Item) in priority order and ask openly to my line manager and other shareholders if we share the same understanding of priorities. From time to time chances are my management team and/or shareholders comment on the priority of PBIs and ask changes. On those instances, we altogether discuss about the motives of these new requests and get fully aligned. At the end of the review we as the team get either confirmation from the audiences regarding the priority order or have an updated list of priority. Here below you can see the ~3 months Product Roadmap of our team. (I’ve intentionally made it blurry for confidentially reasons)
„How to build, maintain and communicate the Product Roadmap?“ weiterlesen
To recall, the fundamental purpose of this blog is to share openly the best practices we had as the Scrum team from a Product Owner Perspective. That’s why it makes sense to share a typical approach we follow while developing new features by cooperating with client development teams with a strict deadline or time pressure. It’s Contract-First REST API Design. A recent example of this was a back-end development of a new Payment channel to sell recurring TV packages to end users through the TV Web portal.
To launch this commercially, the in-house Web portal development team was relying on us to progress further and actively developing the brand-new web pages. Besides, the launch date was fixed and committed to the top-management.
Even though the deadline was approaching, since the earlier Sprint has failed, as the PO, I had to prioritize the relatively small work that was left over at the Sprint Planning event. My perspective was as the whole team had focused to ship the Sprint goal of the previous Sprint and we are pretty close to bring it to Done state, I set a Sprint Goal that dictates to continue to work on the earlier goal and only to take small baby steps regarding the payment solution. My rationale was freezing the work we already had started and progressed a lot and focusing on something totally new wouldn’t be an effective way of utilizing team’s efforts.
„How did we benefit from Contract-First REST API Design Approach?“ weiterlesen
From my perspective, the beauty of Scrum framework is running Sprints for a short period of time (typically 2-3 weeks) and at the end of it being able to judge the team’s overall performance objectively. Setting a goal for a few weeks timeframe and going for it enables the team to get disciplined and stay focused. Historically, we had 6-9 months long projects with potential delays. This leads the teams easily jump into the comfort zone and adapt a relaxed and ‚take it easy‘ type of attitude due to the long time for the project completion. Generally speaking, the human nature has a tendency to delay most of the work to be done towards the deadline. ( Remember your university finales :)) Therefore, setting digestible, S.M.A.R.T Sprint goals developing iteratively and incrementaly is an effective way to accomplish significant achievements within a certain timeframe.
Well, how does the team monitor if bringing the Sprint Goal to DONE status is something already secured or it is at risk ? Even though, it’s not mentioned in the Scrum guide at all, best practices propose „Burndown Chart“ for that purpose. As the Scrum Institute put it precisely:
The Scrum Burndown Chart is a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release. Its purpose is to enable that the project is on the track to deliver the expected solution within the desired schedule.
„How does the Burndown Chart help us to meet Sprint Goals?“ weiterlesen
Let’s imagine a typical Sprint of 2 weeks duration. If the team is delivering software continuously since more than a year it means that the team had run around 26 Sprints past year. Do you think it is feasible that each and every Sprint has been finalized with success? Obviously, it is not surprising that a number of Sprints fail to accomplish the Sprint Goal. Well, even though it’s not the best scenario, a mature Scrum team is supposed to manage mentally and emotionally the consequences of a failed Sprint.
Every professional aims to be successful at personal level. Similarly, everybody enjoys being part of a winning, successful team. Nevertheless, it is very likely that a Sprint could not achieve the targeted Sprint goal and fails due to several reasons such as bad planning, dependencies, challenging Sprint goals, changing scope etc.
„How to handle a failed Sprint and how to avoid it ?“ weiterlesen