Automating Information Security Compliances & Privacy Laws for fast growing SaaS companies. Use Sprinto to obtain information security compliance, close enterprise deals faster, and pass vendor security assessments easily.

Sprinto

sprinto

The sprint is not just about the stories you deliver, and your commitment is not only about you. By committing to the stories that make up the sprint, it is crucial to consider the time and mental effort required for other phases of the . development cycle In an agile environment, we have many meetings and processes that go beyond individual story development, whether we like it or not. Let's consider two scenarios, both with 2-week sprints and a commitment of 8 points. The sprint has just started, and you have a superficial understanding of what needs to be done in the story you committed to because you didn't fully understand the acceptance criteria. You chose not to ask, thinking things would become clearer during development. Scenario 1: When you open the code, you spend an hour trying to find the file with the necessary component for the change and another two hours understanding how the components communicate. After a lunch break, afternoon meetings, and, with luck, another hour of coding, the workday ends. Days pass, and you get stuck, a common occurrence in our field. However, instead of seeking help from a colleague (whether through "rubber ducking" or pair programming), you feel like you have time, and you'll surely figure out the solution on your own. After all, there's still more than a week until the end of the sprint, so you don't communicate your difficulty to the rest of the team and decide that the best thing to do is to think about other things (sometimes it is), and you end up getting lost on the world wide web without solving the problem. Three days before the end of the sprint, you still haven't understood the acceptance criteria, so you ask the Product Owner (PO) about the business meaning. He explains that you believe you understand and start implementing. However, you are interrupted by an afternoon refinement meeting in which, without understanding which stories need refinement, you adopt a passive stance, not contributing to the discussion. One day before the end of the sprint, your is concerned, your story is crucial for the sprint goal, you are a bit tense, just submitted the PR for review. The result? Four open tasks, 11 comments, and an implementation that needs to be redone due to a misunderstanding of the business rule. Definitely not going to make it in time. Scrum Master On the last day of the sprint, the sprint goal is not achieved. (Certainly, it may seem absurd, but it happens more often than one might imagine.) Same 8 points, you have clarity on what needs to be done in the story. In fact, you've already written some personal notes to assist in the implementation, a result of the time invested in refinements. The first hours of the day go well; near lunchtime, you encounter an unforeseen problem and request a "rubber ducking" session with a colleague, which fortunately resolves the issue. Scenario 2: At the end of the week, your code is implemented. On Thursday, you open a Pull Request (PR) and request reviews from colleagues. While waiting, you review backlog stories that need refinement. At the end of the day, you help a colleague solve a technical problem related to the business rule and finish the day. On Friday, colleagues leave comments on your story. You realize you forgot to remove an unused parameter and that your new function can be optimized. You work on these improvements and send the new PR. Your colleagues are agile, and the merge is done before lunch. There is still a week left in the sprint. Your PR is integrated, and you can actively dedicate yourself to helping other colleagues. There is time in the schedule and, most importantly, mental space to actively participate in meetings. You review colleagues' PRs and take the opportunity to study a technical topic that you recognize as a weak point. On Friday, before the end of the sprint, neither you nor your team are stressed. Everything has been delivered. This scenario, not as fictional as it may seem, illustrates how a software developer's work goes beyond delivering story points. It involves commitment and participation in the entire development cycle, assisting colleagues, and learning business rules. Time management is crucial, and realizing that the sprint is more than an individual commitment is crucial. My suggestion is to learn time management, commit to stories considering refinements, presentations, and , and, most importantly, understand that these things are as important as the points you deliver. PR reviews

Working in Agile Environments: The Sprint is Not Just About You

After years of supporting Mozilla financially and spreading messages with my peers, I returned as an active contributor. I defined a 4-week sprint for myself that started on November 22th and finished on my birthday, December 22th. My goals were: 1: To contribute to the localization every day, including weekends. In the beginning, it was hard for me to build a habit of using the little free time I had to contribute to the L1on instead of watching a short documentary or something funnier. After the third day, I nailed it. It helped that I added a reminder for myself in my work calendar and that my current employer supported me with this mission. 2: To ensure that Thunderbird is 100% localized in Bulgarian (it was around 67% at that mark) Now it's a 100%. I could also contribute with a few strings to the Turkish and Czech translations. The next step is to ensure that the translated content makes sense to the end consumer. That's the goal of my next sprint. 3: To ensure that Firefox Focus for Android and IoS and the Facebook Container will also reach 100% localization. It's 100% now. I don't know how many people use it in Bulgaria, but if they want to, it's translated entirely. That was a concise task, thanks to the efforts of the other translators in the past. I translated the delta between January and November 4: To reconnect with the local and international community to contribute more to the project. This is where I need to invest more. I was active in the past, traveling and talking about Mozilla at local and international events and actively building the Bulgarian and Balkan communities. After that, I gave up for reasons I don't want to comment on now, partially because of my personality and ego. I've lost a lot of great friends and peers from Mozilla. I am trying to reconnect with them now. 5: To find another way to help Thunderbird apart from localization and donations. I am now active in the Thunderbird support forum and validating bugs under Linux in Bugzilla for Beta and Daily versions. I would invest some time there as well into my next sprint. Be creative, be brave, and contribute to the open source as you can with your time, knowledge, resources, or good intentions. Also published . here

Everything I Achieved With My Mozilla Contribution Sprint 

For anyone who's ever worked with Research & Development (R&D) teams, the term 'sprint' should sound familiar. The methodology that has transformed how product development takes place. But what if I told you that this same approach, primarily associated with R&D, can and should be applied to Learning and Development (L&D)? How R&D Sprints Work and Why They’re Effective: For those not familiar with the term, sprints in R&D are short, intensive work cycles, typically spanning two weeks. Within this period, teams aim to achieve specific, predefined goals. Unlike traditional project management models, which can span months or even years, sprints prioritize intense bursts of focused work aimed at achieving targeted, predetermined objectives.\Sprints offer many advantages, they include: : What sets the sprint model apart is its systematic approach to achieving milestones. At the outset, teams discuss, debate, and decide on the specific goals they intend to accomplish by the sprint's end. This clarity ensures that each member is aligned on the task, effectively creating a unified force working toward a common purpose for that sprint. Sprints are focused efforts : The sheer brevity of a sprint, with its constrained two-week timeframe, imparts a sense of urgency. Teams are more inclined to be proactive, make decisions promptly, and remain committed to their tasks. The clock, in this context, is not an adversary but a motivating ally. They are time-bound : Sprints are not just about speed and urgency; they champion adaptability. In a constantly changing business landscape, the ability to pivot and adapt becomes a crucial asset. Traditional models, with their elongated timelines, often find themselves ill-equipped to accommodate swift changes. But sprints, with their shorter cycles, allow teams to be nimble. Sprints create a culture of adaptability : At the end of a sprint, teams don't rush into the next one headlong. Instead, they pause, reflect, assess, and glean insights from their recent experiences. This post-sprint evaluation serves as a vital feedback loop, ensuring mistakes are not repeated and strengths are further honed. Teams gain an immediate Impact Essentially, R&D sprints are a testament to what focused effort, time-bound, adaptable, and continuous evaluation can achieve. Why L&D Should Apply the R&D Method: The sprint method fosters a culture of continuous learning, adaptability, and collaboration within organizations, which are the defining characteristics of a successful L&D department. Applying the R&D methodology to L&D practices isn't just about copying a formula, and it’s not about compressing extensive courses into tight schedules. Instead, it signifies a shift away from long-term engagements and an emphasis that is no longer about quantity, but on sharp, precise, outcome-focused learning. Sprint-based learning it's about reimagining the role of L&D in a business and making L&D a crucial driver of employee mobility, retention, and satisfaction, as well as a means of meeting business KPIs. But why consider the sprint model for L&D? The upsides are considerable: : Sprint practices streamline learning. Traditional coaching or mentoring programs can take anywhere from 6-12 months to complete, and in a lot of cases, they’re open-ended, without a clear goal. The result is that many HR teams receive lukewarm feedback from the business and without a clear benefit, many “we don't have time for it” excuses. Using a sprint approach, however, coaching and mentoring are focused on a limited amount of sessions (around 5) that take place over 6-8 . The result? Better engagement and swifter goal realization. Efficiency weeks : Beyond shortening timelines, sprint models are focused on specific goals. Alignment of objectives eliminates ambiguity and requires that L&D programs be led by experts, rather than generalists to ensure precise goal achievement. If one needs to learn how to negotiate better, working with a negotiation expert is ideal, and not a life coach or a communication trainer for example. Collaboration takes center stage as we engage with experts, ensuring that every step of the learning journey is rooted in authenticity and expertise. Purposeful learning : Since sprints are time-bound, L&D teams gain the benefit of immediate assessments that enable timely course corrections, the ability to quickly measure the progress and success of every program, and, more importantly, the ability to course correct if results are not as good as expected. Quick feedback The Case for Sprints in L&D: When L&D programs align with overarching business KPIs, they elevate the entire organization. In the current landscape, where every dollar spent is under the microscope, sprint models in L&D emerge as an ideal solution; ROI is quick, clear, and easy to justify since results can be measured against business goals. But it’s not just the acceleration that’s noteworthy—it’s the transparency. With sprint architectures, results are palpable, quantifiable, and critically, assessable. While the sprint methodology might trace its roots to R&D, its applicability is ubiquitous. L&D is at an inflection point, where operational efficiency, strategic alignment, and tangible ROI converge. Now is the time for L&D to harness sprint magic to redefine the learning journey. Also published . here

Innovating L&D: How Sprint Models from R&D Improve Efficiency and Effectiveness

Nowadays, there are a lot of teams that build their workflow using the Scrum approach and its ceremonies. Sprint planning is one of the significant parts of this process, which allows the team to understand the scope of issues that they will solve during the sprint and evaluate and prioritize them by the value for the client. Indeed, planning is the foundation of a Scrum-based management framework. It helps arrange a team, set goals clearly and achieve them. To reach success, a preparation for the next sprint or release should go toe to toe with a clear understanding of what is the scope of the project, what is the sequence of issues in a workflow, who is in charge of performing each task, how much effort and time does the team need to do tasks from the scope, and, finally, what will the team do if stakeholders bring new urgent tasks during the sprint or release. It seems easy to give the answers to these questions, however, a lot of development teams have faced poor planning procedures and their lamentable consequences. This article is dedicated to the planning version that is accompanied by my personal comments and notes. I believe that this can improve the process and distribute the initiative between all the members, which eventually leads to better outcomes. Signs of Inadequate Planning Improper scheduling destroys all team workflows, increases demotivation and burnout among team members and cultivates negligence from both the team and management. Here are points typically associated with poor scheduling: Delay by more than 20% in the performance of the task; Permanent postponement of the task due to non-fulfilment; Implementation of the plan in advance, reassessment of tasks; Underload of employees, occasional lack of tasks for reasons such as dependence on other departments or employees, lack of medium-term plans; Constant rescheduling of tasks due to unplanned urgent work; Lack of time for internal improvements (automation, technical debt, retrospective, etc.); Permanent and/or long-term overtime work of the team. Although developer teams encounter such problems, in many cases, they don’t try to change the process. There is a common misconception that only the project manager, product owner or other manager can facilitate the planning procedure. I sincerely believe that no matter what role you play in your project, you, just as any other teammate, can use the following approach to get it going and get others involved to rally the team on the path to change. Further in the article, I would like to propose a planning system to help get it working. But first, let’s look at the principles. Goals and Principles of The Proposed Planning System First of all, the goals of the planning system should be clearly described to show some of the benefits that can be obtained by using it, such as: Increasing the transparency of the release process and the timing of its delivery to the client, for both business and team members; Creation of a release roadmap; Including in the release not only tasks important from a business point of view but also technical tasks — technical debt and bugs that allow improving the product and/or cover the requirements of related departments; Reducing the involvement of all team members in planning and giving them time to perform more important tasks instead of attending a meeting in the background; Increasing awareness and control by leads of technical debt, bugs and technical issues in tasks of their streams; Increasing transparency of issue management via Jira. Before describing the planning process from my point of view, it is vital to formulate a few principles that underlie this system: Each release should include X sprints lasting 2 weeks, where X is the number of sprints that were agreed by team members. For example, in my team, we have 4 sprints in a release; For each sprint, you can plan only 70% of team member work time — 30% is reserved for unplanned tasks and other activities; The capacity must be calculated for each worker separately. Tasks must be assigned to a responsible person during the planning session; Epics, user story or any other unifying entity with a long live cycle (more than 1 sprint) should not have a sprint, but should have a Fix Version; Every task in Jira should be a part of an Epic; All tasks shall be in Jira, even if it does not relate to the release development activities to log time. This will directly show what team members have done during the sprint and help to get a "good" burn-down chart; Only bugs, tasks and test executions can be a part of the sprint. In other words, issue types that could be solved and closed; Every task should be estimated before adding to the sprint; Jira tickets should still be assigned to the responsible user after resolution; For each subgroup (analytics, development, testing), a separate Fix Version of the backlog should be created that contains corresponding issues; Next points if the team commits time in Jira: Time spent on Jira tickets should be logged in Jira. It can be done by any member of the team; Tasks are planned with an accuracy of half a day for most situations. Planning Description The following approach suggests splitting one long meeting into 4 events: 2 days for independent work of the subteam and 2 days for meetings of leads. The time spent at each stage depends on the number of team members and responsible persons, such as team leaders who take part in the planning sessions. It shortens if leads participate in the life of its streams actively to reveal the necessities of their subordinates in advance and add tasks to the backlog in time. During these activities, the team plans the working scope for the next release and the first week of the sprint of the next+1 release. To explain the necessity of why we need to schedule tasks for the next+1 release in part, here are several detailed reasons: Since different streams have a shift in accordance with the development pipeline, when one group ends their tasks, the other subteam should take them to work. However, the first subgroup should not have gaps due to the lack of tasks to complete, so we have to take this feature into account when planning; Because the planning session is done after the end of the previous release, at this stage it is obvious which tasks were not supposed to be completed and taken into consideration in the current release; What is more, it allows us to increase intervals between planning sessions, which reduces the time spent by event participants. Day 1 ~15-60 min Time: a placeholder in a calendar Schedule activity type: On this day (e.g. Monday), subteam participants are assigned placeholders in calendars for their own work on lists of preferable tasks for future planned releases. Of course, this activity can be performed by team leads of each stream on their own or by organizing meetings with stream members to discuss faced or desired issues and evaluate their importance for future product versions from a stream perspective. However, I highly recommend teaching team members to participate in this part of preparation because it can help leaders to recognize the needs of their subordinates and manage task inclusion respectively. As advice, to simplify creating Epics and tasks in Jira your team or the Jira service team of your company could develop a script to automate this routine process. Goals Collect all tasks using Jira for the next fix versions by subteam members Description At this stage, each subteam collects all tasks to evaluate and prioritize them in the future. For the sake of increasing transparency between subteams, these issues should be created in Jira for estimation and planning in the next releases. Activities Each subteam creates a list of desired tasks for the next Fix Versions including tasks from their backlog;Participants create Epics and Tasks in Jira for each issue from the list and estimate them by story points or work days;In addition, the Fix Version corresponding to the release is assigned to all created tasks in Jira. At the start of planning you use Fix Version as a container that collects all tasks that come both in releases and in sprints planned for them. Note: Day 2 ~15-60 min Time: a placeholder in a calendar Schedule activity type: During this stage, the leads of every subteam validate issues that were created by other subgroups and evaluate labor costs from their teams. Evaluation can be done by using story points or work days. Completing estimation is essential for future milestones because it helps to fill sprints according to the capacity of each teammate. In the case when leads can’t estimate some tasks they should first check the description in the Jira task and specifications from business or system analysts, and second arrange a meeting with the necessary participants to complete this phase. If your team works with the business team closely, after finishing this estimation session you can establish a meeting with stakeholders to get priority goals and features for the product from a business perspective. It allows your team to assign priority for choosing tasks in releases accurately. Goals Review tasks of other subteams and their put labor costs estimation from each subteam to perform them in the next releases Description This activity is necessary in order to get a comprehensive assessment of user stories and release issues Activities Leads from different streams evaluate the labor costs for completing Epics and tasks created by other subgroups. They can attract or organize additional meetings with the necessary participants to set an appropriate score Day 3 ~30-60 min Time: a meeting in a calendar Schedule activity type: This phase follows one key purpose, which is allocating all Epics and tasks that were created at previous stages of planning to the two next releases according to their capacity. Note that filling release capacity should be taken into account. The capacity is the total amount of working days, for example, for a 2-week sprint, the capacity will be 10 working days (if a worker doesn’t have vacations, holidays, etc.). As a result, the next releases will have the subsequent percentage of capacity: 70% of the total capacity for the Fix Version N or 7 workdays; 35% of the capacity of the 1 sprint of the fix version N+1 or 3,5 workdays. In addition, if you take into consideration the different types of tasks that your team regularly encounters, you can allocate them to the planned capacity of each team member as well. For instance, 21% – technical tasks, 21% – features for clients, 18% – launching the release and its support, and 10% – bugs. Goals Plan Fix Versions N and N+1 entirely Description The main purpose of this day is to completely fill the release N and partially the release N+1 and commit the goals of each of them Activities Setting the goals of each release;Epics and tasks review and their allocation on the 2 next Fix Versions according to their capacity;If subteams didn’t provide enough issues for releases, additional tasks shall be taken from an individual backlog of each subteam. As said before, a backlog of each subgroup should be marked separately by a backlog Fix Version. Note: Day 4 ~30-60 min Time: a meeting in a calendar Schedule activity type: This is the final day of the planning procedure that is required to allocate all tasks from Fix Versions to sprints. Firstly, issues from release N should be distributed to all sprints that your team is determined to work on. Likewise, the release N+1 allocates to its first sprint considering capacity. Goals Plan all sprints for N Fix Versions entirely and the 1st sprint of N+1 Fix Version partially Description The goal of this phase is to fully schedule sprints for the next Fix Version and plan the first sprint next+1 Fix Version. At this point, the team already has goals for Fix Versions and the list of tasks, but the team needs to add it to sprints with respect to the development pipeline for each task Activities Distribution of the list of tasks from release N to sprint S and release N+1 for the 1st week of sprint S+1 in accordance with the pipeline;Assigning sprint numbers to tasks;Removing Fix Version from issues that will not be included in the final release (they are already linked to a specific sprint); As a result of the above actions, you will receive: The list of tasks included in each Fix Version in Jira which will be released to the clients; The list of tasks included in each sprint according to the capacity of team members. The next iteration of planning will take place on the 1st week of the N+1 release. Your team will have to plan the N+1 release and plan 1 week of the N+2 release. Implementation of The Planning Process Conducting a new procedure often faces counteraction among team participants. Undoubtedly, you, as a promoter of changes, should take this fact into account and interact with the team members to build planning in a smooth and gentle way. The following points might help you to focus on the main phases of implementation and make this process easy: Determine with the team the optimal sprint duration and their numbers for a release. I strongly believe that 1 week is not a viable option and it is necessary to look at the average time of a task completion. Generally, a release demands a minimum 1 sprint for 2 weeks; Define the capacity of your team in story points or work days; Evaluate the amount of unplanned tasks that your team usually receive during a release and determine the percentage of capacity for such tasks, for instance, 30%; Divide the team into subteams such as analysis, development, QA teams, and others, and assign a responsible person for each subgroup; Create a Fix Version in Jira for a backlog of each subteam; Agree with the team on which entities can be included in the Fix Version or the sprint only and which entities – in both of them; Create a dashboard with topical tasks in Jira or in another task tracker that are available to each team member; Present the concept to the team, discuss nuances of the workflow, and commit agreements in Confluence or Wiki page; Start working according to a new approach. Adjust it to the needs of the team and the project. Don't despair, the process will be easier each time. Building the proper scheduling process is considered to be a difficult task, however, this article can help you look at the problem from a different angle, increase communication between all team members, and show them that it is not only management and stakeholders who decide what the team will do during the sprints, but also the team themselves.

Releases And Sprints Planning: A Guide to Elevating Scrum Workflows

Software outsourcing has emerged as a powerful and popular strategy for building products in today's tech-driven landscape. It is not just an extension of the in-house team anymore; rather, it is a fundamental approach that many companies have adopted to build software products. Outsourcing comes with its own share of risks and rewards. While some startup founders are shy and look out for the best engineers, others are brave and build products by outsourcing them. With startup culture booming, not every new venture has the capacity to hire in-house software engineers to build their first product. For many startups, the founders themselves, or outsourced partners, build the initial version. While the YC advises against outsourcing software development, it's essential to remember that every business has unique needs and circumstances. Therefore, the decision to outsource or not lies in your hands. It's less about the act of outsourcing and more about establishing the correct objectives. If you meticulously outline your goals and secure a reliable partner, you are more likely to hit your target. Software Development: The Importance of Process In the heart of product development, one common mistake appears consistently: a rushed jump into product development or attempting to estimate a product and its features by a single sentence. This flawed approach can lead to painful setbacks, regardless of whether you're developing in-house or outsourcing. Therefore, it is crucial to prioritize the process, particularly the Design Sprint. The Design Sprint is essentially the Product Discovery phase on steroids. It aims to assemble just the right amount of product specifications to kickstart development. It's a lean, streamlined process designed to move your product from concept (0) to initial launch (1). Design Sprint: An In-depth Look The Design Sprint is a pivotal phase in product development, a concentrated and fast-paced process that focuses entirely on the product. Unlike other aspects of product development that involve developing a comprehensive list of requirements, testing business hypotheses, verifying product-market fit, or customer development, the Design Sprint zeroes in on the product and its core functionalities. Consider the challenge of constructing a building without a detailed architectural plan. That's akin to undertaking software development without a well-executed Design Sprint. The Sprint ensures that all parties involved – from developers and designers to stakeholders and project managers – are in alignment regarding the product specifications, deliverables, timeframes, and budget. Effective communication during this phase is crucial as it directly influences the success rate of the project. A Design Sprint that is well-executed paves the way for a smoother development process and, ultimately, a successful product. Tailoring the Design Sprint to Project Goals A Design Sprint isn't a one-size-fits-all process; it can be adapted and molded to suit the specific needs and goals of each project. Some software agencies might offer an exhaustive list of product specifications that could be overwhelming for a Minimum Viable Product (MVP). Consider a scenario where your concept is 'Uber for X.' A vendor might suggest a plethora of requirements typical to that product genre. However, it's important to remember that such products have been in the market for years, acquiring a broad array of features and a vast user base. An MVP, on the other hand, does not demand such intricacy. It requires a lean, focused approach that zeroes in on the essential features to provide a solid user experience without unnecessary complexities. Starting a project with a Design Sprint is akin to setting the compass before embarking on a journey. The more granular and precise your steps are, the higher your chances of reaching your destination successfully. Even the main phase of software product development is divided into manageable, bite-sized weekly or bi-weekly iterations, keeping the process agile and adaptable. A Glimpse into the Design Sprint Process The Design Sprint process kicks off once you team up with a software agency. This phase sets the stage for the pilot project, enabling the team to test working assumptions and conduct focused research on product requirements, technical feasibility, compatibility with third-party services, and the creation of tests and project specifications. The composition of the Design Sprint team can fluctuate based on the complexity of the project. In some cases, vendors might allocate a highly-skilled and diversified team. However, for an MVP, your team might be pared down to the essentials: a Project Manager, a Backend Engineer, and a UI/UX Designer. Discussing team configuration, timeline, and budget upfront is a prudent approach to avoid potential misalignments down the line. MVP does not require an exhaustive research phase and should prioritize quick go-to-market timelines Unlike large enterprise projects, an MVP does not require an exhaustive research phase. Startups should prioritize quick go-to-market timelines, avoiding getting entangled in lengthy and costly processes more fitting for larger enterprises. By the end of the Discovery phase, you can anticipate a detailed understanding of: Main use cases User story maps UI examples and clickable prototypes MVP Scope of Work Feature list Details of third-party services and APIs Tech stack details Data structures Assumptions Team configuration for the development phase Estimated timeframe and budget approximations Preliminary weekly plan In essence, the Design Sprint equips you with everything you need to make an informed decision about the project's trajectory. It also provides you with a glimpse of what working with the team feels like. Generally, the Design Sprint for an MVP lasts one to two weeks, much like the subsequent iterations during the development phase. Setting the Right Goals for Your Product The limitation largely arises if you allow the agency to set the goals for your product. The importance of setting the right goals for your product cannot be overstated. One of the arguments against outsourcing to a software agency is that it might limit your ability to iterate on the product. While there is a kernel of truth in this, the limitation largely arises if you allow the agency to set the goals for your product. It's crucial to remember that agencies, much like AI models such as ChatGPT, thrive on specific input. Without clear direction, they might generate broad suggestions around your brand identity, design, and technology. This isn't due to a lack of concern or commitment to their work; on the contrary, it's because they are invested in you and have a process in place to build great products. One valuable principle to remember when building any software product is that you have three main variables to work with: Timeline, Budget, and Features. It's recommended to set a cap on the timeline, as this indirectly limits the budget and features, making both you and the software agency accountable for the outcomes. Most agencies operate on longer cycles, so it's essential to discuss upfront how you'd like your product to be built. To iterate on the product, you need to be involved in the process and share the responsibilities of managing the project with the agency's team. This approach keeps you hands-on with the project, allowing for course corrections and maintaining agility in the process. The Choice Between Software Agencies and Freelancers Choosing between hiring a software agency and assembling a team of freelancers is a critical decision in your product development journey. Each option comes with its own set of advantages and challenges. A software agency offers a cohesive team with a proven track record of executing Design Sprints and building successful products. They come with established processes and can hit the ground running, reducing operational stress on your part. On the other hand, hiring freelancers gives you more control over every aspect of the team and the process. However, this option requires you to manage the process entirely on your own, including vetting potential team members, managing them, and aligning everyone to the product roadmap. This can introduce additional stress and operational overhead. Ultimately, the choice between a software agency and freelancers depends on your specific needs, your comfort level with managing a team, and the complexity of your product. In the rapidly evolving world of software development, outsourcing has become a prevalent strategy, offering a wealth of benefits from cost-effectiveness to access to diverse skills and experience. However, it's critical to approach outsourcing with a well-defined process and clear goals. This is where the Design Sprint plays a pivotal role. A well-executed Design Sprint can act as a blueprint, guiding your product development journey from inception to initial launch. It aids in aligning all stakeholders on product specifications, deliverables, timelines, and budget, thus enhancing communication and increasing the likelihood of project success. The crux of a successful outsourcing venture lies in setting the right goals for your product and ensuring your chosen partner, be it a software agency or a team of freelancers, aligns with those goals. By capping your timeline, you inherently limit your budget and features, enabling you to maintain control over the project's direction and outcomes.

Unpacking Design Sprint in Software Outsourcing

When conducted effectively, design sprints can help teams accomplish several months’ worth of work in just a few days. However, when ran poorly, they can only cause the team to lose time while making no progress at all. As an ex-Googler and now a designer at Meta, I have run and participated in numerous design sprints, some of which lasted only half a day and others took weeks. While there are multiple online resources available that shed light on effective design sprint practices (e.g., method), in this article, I would like to share 5 tips on how to run result-focused design sprints, based on the common pitfalls I’ve observed in my experience. Google’s 5-day Design Sprint But before I delve into each of the 5 tips, here’s the I’d like you to have: key takeaway Don’t run a design sprint just for the sake of it; focus on driving meaningful outcomes for your team. Customise your sprint structure and activities to maximise results. Now, let’s take a look at those 5 tips: 1. Prepare Opinions Ahead of the Sprint The key to a successful sprint lies in , which has several aspects to it: preparation Start by creating a clear that addresses such questions as: sprint brief Why are you running the sprint? What is the ideal outcome of the sprint? What key questions should be answered during the sprint? What is within the scope, and what’s out of the scope of the sprint? Who should be invited? Next, decide on the , including: sprint logistics The schedule; The activities for each session; Figmas or FigJams for people to collaborate in (make sure to provide all the relevant screens, assets, and components to save people time from re-creating elements). But most importantly, formulate opinions: Which ideas do you find most promising and would like your participants to explore? If you are running the sprint, most likely you are the domain expert. However, it might take some time for your participants to familiarize themselves with the topics. To avoid missing key ideas, it's recommended that you suggest some starting points for them to explore. After the sprint, which direction do you think the team should take? While you don’t want to overtly dictate the course of action, you still need to have a viewpoint on the product and its design. The key is to have , so you can guide the team in the right direction but also adjust ideas as necessary. strong opinions, loosely held The bottom line is this: if you, as the domain expert, don't have coherent ideas at the beginning of the sprint, how can you expect others, who have spent less time on the topic, to form opinions in such a short period of time? 2. A Generic Icebreaker Is a Missed Opportunity Every activity in the sprint is an opportunity to stimulate thinking, even the icebreaker. When kicking off the sprint, think of warm-up exercises that can both engage the participants while also prompting them to think about the topic at hand. Suppose your sprint is focused on making your app more “effortless” to use. In that case, ask your participants to think of products, both physical and digital, that they would describe as such. The goal here is to encourage the participants to think about the concept of “effortlessness”. 3. Acknowledge and Address Misalignments The key goal for sprints is usually to drive alignment and bring everyone on the same page. When running a sprint, don’t shy away from misalignment or conflicts. Instead, acknowledge them, and use them to your advantage. A great way to do this is through the "Spicy debate" activity, where two opposing opinions are placed on the two ends of a scale. It then encourages the other participants to share their views on a question and place themselves on the scale accordingly. Here’s an example: Although it may seem counterintuitive, this activity can help create a safe space for diverse opinions and ultimately lead to greater alignment. By calling out misalignments and addressing them head-on, you can work towards resolving conflicts and achieving your sprint goals more effectively. 4. Allow Adequate Time for Idea Development Sprints always feel rushed. This is the nature of a sprint; they are designed to be fast-paced. Yet, in order to drive meaningful results, it is crucial to provide adequate time for the team to fully absorb information, reflect, and explore ideas. Remember, simply running a sprint does not guarantee that valuable ideas will emerge. If you are running a multi-day sprint, it's important to strike a balance between group collaboration and individual focus time to allow for productive work. Here’s an example schedule for a two-week sprint: Don’t rush people by scheduling too many stand-ups or check-ins. Give individuals, especially those who thrive when working alone, enough time to do heads-down work. 5. Focus on the ‘Why’ - Tailor Your Process and Outcome Finally, and most importantly, I want to emphasize once again the importance of focusing on results. Throughout the sprint, you need to maintain absolute clarity on “why” you are undertaking the sprint and “what” you aim to accomplish. This will allow you to determine "how" to best navigate the sprint and achieve your desired outcomes. For example, if your goal is to create a north star vision to secure leadership buy-ins, focus on generating excitement amongst the sprint participants and producing a high-quality vision artifact as an outcome to drive buy-ins. Alternatively, if your goal is to align on the immediate next steps for a project, focus on hashing out the details of the features. In this case, it's best to avoid wasting time creating polished artifacts and instead prioritize designing the features in detail. To sum up, design sprints are a powerful method that pushes teams to move fast. However, it's important to remember that While running a design sprint can be a fun and rewarding process, its the sprint itself is only a means to an end. true value lies in driving meaningful results.

Stop “Running” your Design Sprints: Prioritizing Results Over Process

A key feature of the Scrum framework is the ability to plan our sprints and releases by evaluating the work capacity of our team. This becomes much more difficult if we don’t have a standardized way of estimating the size of our tasks. In this article, we will cover the two most common approaches to product backlog item estimation, story points and ideal days. What Is A Product Backlog Item? The product backlog, or the desired list of functionalities for our product, consists of Product Backlog Items, or PBIs for short. PBIs are mostly features that will provide a tangible value to the end-user or customer and are often written as user stories. They could represent something brand new (like a login screen for a new website), or an update of an already existing feature (an update to the loading screen of an older website). Additionally, PBIs can include defects that need repair, technical improvements, or knowledge acquisition. User stories are a way of representing PBIs so that they can be easily understood by both the business and the technical side of the company. They are written from the user’s perspective and clearly state what the feature is, as well as the benefits it will have to the end user. Characteristics Of A Good Product Backlog When managing your product backlog, it’s important to keep in mind some basic principles that constitute a good backlog. Those principles are contained within an easy-to-remember acronym, DEEP. 1. Detailed Appropriately Not all items will be at the same level of detail at the same time. As a story progresses through the backlog it should become more and more detailed so that the items at the top of the backlog are very specific and elaborate so that they can be worked on in near sprints, and the things at the bottom are broad and more extensive. As a larger item progresses it will be broken down into smaller and more specific items that can be worked on. 2. Emergent As long as the product is being developed or maintained the backlog should never stay frozen. Through the process of grooming, new PBIs are constantly added, old ones are refined, and some are even discontinued. It is very important that the backlog is updated frequently and failing to do so can cause a mountain of problems down the line. 3. Estimated Now comes the product backlog principle that interests us the most in the context of this article. Each PBI should have a size estimate that represents the amount of effort needed to complete that item. The product owner then uses this estimate as one of the several inputs to determine the priority of an item in the backlog. 4. Prioritized Even though the product backlog is a prioritized list of PBIs, not all items should be subjected to careful prioritization. If an item is scheduled for Release 2 or 3, it might be wasteful to dedicate time and resources to prioritizing it so far in advance as a lot of aspects of our project may change. As a general rule of thumb, you should try to keep your prioritization efforts confined to the items scheduled for the current release. PBI Estimation Concepts Before we dive deeper into tools you can use to estimate your product backlog items, let’s quickly reflect on 4 important concepts that you should keep in mind while conducting the estimation: The whole team should participate in the estimation process as this is one of the principles , it’s methodological parent. The product owner should be there to describe the PBIs and provide any clarification that is needed, however, the development team should provide the final estimation as they are the ones that will be doing the work. Estimate as a team: connecting Scrum with Agile : If estimates are treated like worker commitments, the workers will in most cases overestimate the effort to not risk breaching the due date and incurring some penalties. For this reason, estimates should stay exactly that, estimates. Estimates are not commitments We should aim for the estimates to be accurate, without being overly precise. In other words, they should be in the ballpark of the actual effort that this item will take to complete. Aiming for precision will often expend too many resources without providing much additional benefit. Accuracy over precision: The estimates should be size comparisons to other items and shouldn’t be in the form of absolute sizes as people are generally much better at the former. Relative size estimation: What Are Story Points? Story points measure the magnitude of a PBI by taking into account the size of the item as well as its complexity. Some items may not be that large but are deeply technical and complex, while others are large but fairly trivial. These stories represent different challenges, however, they will require a similar amount of effort. That’s why both of these parameters need to be taken into account. The final goal of story points is to be able to say “If story 1 is two story points large, then story 2 is an eight”, implying that story 2 is four times the size of story 1. When our story sizes are properly estimated, we can use our team’s average velocity (the average amount of story points our team completes in a sprint) to calculate how many sprints it would take to complete some parts of our backlog. We can do this by taking the total story points from the PBIs in that part of the backlog and dividing them by our team’s velocity. Pros of story points It’s much easier to estimate velocity than with ideal days It abides by the “relative measures only” rule for product backlog items much better than ideal days Cons of story points Abstract and harder to understand- It’s Harder to get a time estimate and create a schedule It will require a decent amount of work to educate the team and the stakeholders about this method What Are Ideal Days? An alternative approach for estimating PBIs is to use ideal days, or the number of effort-days or person-days that are needed to complete a story. One thing that you should keep in mind is that ideal days are not the same as elapsed time, they represent the number of days a team or a person will take to complete the story if they had no other distractions or interruptions. Pros of ideal days: It’s intuitive and concrete Clients and stakeholders understand it more easily than story points Cons of ideal days: People are usually bad at estimating time Risk of stakeholders misinterpreting ideal days as time commitments Which Is Better, Story Points Or Ideal Days? This question doesn’t have write or wrong answer. The best thing you can do is evaluate the pros and cons of each of the characteristics of your team. Even trying out each of these for some time wouldn’t be bad as you can better get a grip on what works better in your context. I tend to sway in the direction of story points primarily because of the advantages it has when it comes to calculating velocity, as well as the great risk of ideal days being misunderstood as commitments. Even though most teams tend to go for story points these days don’t let that stop you from trying other approaches and determining what’s the best approach for you and your team! Also published . here

Scrum Sprint Planning: Should You Choose Story Points or Ideal Days?

It’s time for the next generation of Scrum: no Sprints needed. If you’re a small cross-functional team aiming to quickly deliver working value to your customer, pick the number one business and user need and build it. Get feedback, adjust, and release. Then pick the next one. Just deliver. Don’t throw in whatever a [time box] can fit. It’s not a container – it’s the lowest risk period of time teams try to manage. If you think the more tasks you throw in, the higher the chance to release – you won’t deliver anything. Waterfall One can only understand Sprint Planning and time-boxed Sprints if one has worked in a pure waterfall project that lasted, let’s say, a year and a half before anything was released. What is released at the end of such a cycle is basically a new product, almost completely incompatible with the previous version. The release notes are five pages long (that no one reads), and it takes another year to get existing customers accustomed to new versions. Most customers are unlikely to upgrade because the minor inconveniences a new release fixes isn’t worth the investment. I remember one of the most impressive presentations about Agile Transformations. Large enterprise virtualization company. They used to release a new version once every two years. But the average time a customer used to get a new version with a change request of theirs in it was … wait for it .. four years. Because, just like enterprise vendors, enterprise customers are not agile. It was impressive because they managed – the vendor – to transform and went all Scrum after months of training and experimentation. At the time of the presentation, they had teams that had started releasing directly to their customers every two weeks. Good Sprint Four years versus two weeks – that’s the power of Scrum when done with the right intentions and the right way. What is the right way? Decide and commit on all levels. The risk mitigation superpowers of the time-boxed Sprints are based on simple mathematics and faith in destiny. You need to be a little superstitious to make it work. Remember – if anything can go wrong, it will go wrong. Murphy’s law Now, don’t get me wrong (unintended) – this is not about fear. This is about being reasonable. Information technologies are the fastest industry today. It’s one of the most complex ecosystems. There are tons of dependencies agile teams navigate through every day, most of them unplanned. You need while dealing with the inevitable daily surprises. practices to help you be productive There’s another famous law – a deficiency in any one of a number of factors dooms an endeavour to failure. Consequently, a successful endeavour (subject to this principle) is one for which every possible deficiency has been avoided. And here’s the question – to make sure your endeavour is going to be successful? for how long can you avoid every possible deficiency Can you make sure that all internal and external dependencies to your product and team – people, tools, resources, world economy —  will remain stable and in a condition favouring your goals for six months, one year, two years? No, you can’t. That’s why here comes Scrum with its safety net of time-boxed Sprints. One to three weeks sounds foreseeable, feasible, and low risk. We might try to get all conditions in place to deliver high-value and high-quality to our customers within two weeks or less. Sounds achievable, right? We have the time to consider the risks and continuously get feedback on customers’ top needs. The developers confirm they understand those top priorities and have everything they need to implement and deliver as expected. The expectation is to work and to receive it sooner than four years. Release early and release often. Once you master this, remove the Sprints and release earlier and more often – several times a day, for example. Sprints enable to happen at all. continuous delivery Scrum and Sprint Planning are a good step toward limiting and avoiding the risks of delays, not delivering at all, rework and waste and throwing months of work in the bin because no customer will get it. What’s sadder – no customer might need it anymore at the time we release it already if there were no Sprints. Bad Sprint The problems with Sprints begin when we start mixing Time and Space. And instead of perceiving “time-boxed” as a limit for time, we interpret it as a container for tasks and start throwing as many tasks in the “box” as it can fit and some more on top in case we finish some earlier. As if it has ever happened. And this is when our Scrum fails. Еngineers are not superstitious. They are opportunistic. They believe nothing can ever go wrong, and their plans are foolproof. They don’t believe in risk. That’s what lets them drive world innovation and technology but this approach has some downsides. The worst thing we can do in Sprint Planning is to initiate it with the question, “How many tasks can we fit in this Sprint?” This is the root cause of all evil we’re witnessing in Product and Engineering management nowadays. It doesn’t matter how many tasks your team they can do in one Sprint. What matters is which task they can get done that your customer can begin using at the end of the sprint. thinks If you don’t have a strong Product Goal turned into Useful, Meaningful, Feasible, Releasable that your team can commit to delivering with , and if you don’t have a clear vision and mechanisms how to handle the that will inevitably occur during the Sprint, your Sprint Planning is useless and a waste of time. descriptions of users’ needs first high quality unplanned deficiencies Throwing tens of items in that box doesn’t increase the chance to . at least release something On the contrary, it’s a sure way to failure and team demoralisation. There are two scenarios for bad Sprints. The one above is the most common occurrence – trying to add as many work items in the Sprint as the suggests. Have you noticed how we never plan as many stories as is the average velocity despite the Velocity charts? We always add more. velocity I cannot count how many times I’ve heard: “Oh, we have for some more story points. Which tasks should we add?” a capacity “Let’s leave some for bug-fixing.” capacity “Nah, let’s Sprint, and we can always the ones at the bottom if we see we can’t complete them at the meeting.” plan the whole remove grooming Guess how the Sprint ends. We manage to get a couple of tasks done, 18 stories are to the next Sprint, and 6 are moved back to the backlog. almost moved That’s why it’s called a backlog – it’s the log of everything we moved back. The other scenario of Sprint Planning failure is when the . This is actually the best thing if it’s on purpose, but when it is because the product manager does everything except figuring out what the most important features, fixes, and improvements are, which we should do first in order to meet customer expectations, grow our business and advance with our technology, this is a symptom of a burned-out product manager, wasted team effort and motivation, and irritated stakeholders. This is when the product manager gets fired. product backlog is almost empty The Next Generation Scrum We need new Scrum terminology for the 2025 edition to get people to get it. Let’s try to reimagine the next generation of Scrum: Timebox becomes . Low-Risk High-Efficiency – Streamlined E.g., The daily meetings are streamlined. The Sprint becomes good old because, with Sprints, we forget to build and get feedback and then build and get feedback again until the user is happy and we’ve reached our goals. Iteration iterate – E.g., What customer value are we going to deliver this iteration? Rather than sprinting (literally being in a rush because it’s a huge story) and coding for five Sprints and eventually caring to get feedback. That’s not agile. The Product Backlog should be straightened to because apparently, repeating a thousand times that the Product Backlog should be ordered by priorities is not enough. That’s why we should start talking only about Product (Business, Customer) Priorities. It implies thinking about what’s most essential and game-changing for the business compared to a To-Do list with random notes. Priorities E.g., Which are our top priorities as a company? No Sprints. Just deliver. Now, we clarified that all that matters is the company’s strategic goals, the business development plans, the customer needs, the technology evolution, and the product vision – we have to just start working on them. the Priorities – Which one to choose? Which one is the top priority? I like the idea of the one that will make the most significant difference – in quality and quantity. The one that will enable the . The one that will open the largest market expansion. The one that will bring more customers. In terms of quality, it’s called (appropriateness, completeness, correctness). highest growth Functional Suitability The one that will and increase your product (maturity, availability, fault tolerance, recoverability) and Performance Efficiency. If your system had a significant downtime last month, then you need to invest in your infrastructure – also Reliability. retain all customers Reliability The one that will offload customer success teams so they can really focus on success . instead of support. The quality characteristic to make this happen is (learnability, operability, user error protection) Usability The one that will make the product (modularity, reusability, analysability, modifiability, testability) more efficient. That’s the one that will of bug-fixing, lower the regression risk, and by enabling continuous delivery. Maintainability reduce the cost speed up the releases It might be that the last big feature was heavily delayed because of unforeseen regression issues. Then the one you should probably prioritise is cleaning tech debt and heavy refactoring. It will again increase your maintainability. There will be a few items in that priority list that are equally important. The prioritisation strategies differ depending on your business context at the moment. It might be that a big fish customer is knocking on your door. Then you’d go with the new big feature they are waiting for. This is the of your product. And the entire Team should start working on it together. Functional Appropriateness Whatever your current product situation is, account for it and always lean on the one that increases the quality of your product and service. It’s always the right choice. Once you decide what your goals are, it gets easy. . Let them think and ideate, let them draw and scratch, let them get loud, let them play, let them build features they are proud of, you are proud of, and your customers are recommending. Let them deliver your five-stars product to your thousands of happy customers. Gather the entire team together and let them create You don’t need Sprints to do that. You need a clear vision and Priorities. Decide. Commit. Succeed. Also published . here

The Next Generation of Scrum: No Sprints Needed. Just Deliver

My talk was accepted by SpringOne in San Francisco. I never went to that conference and was really looking forward to it. This year would probably be amazing with the Spring 6.0 and Spring Boot 3.0 releases. So many groundbreaking changes. Unfortunately, my travel budget at Lightrun was cut, and I eventually left. This meant I had to cancel the trip, I would have paid for travel, but San Francisco is both far and prohibitively expensive. I’ll have to take a raincheck. This isn’t exactly a substitute, but a skeleton Spring Team is on a “world tour” which reached Tel Aviv last week and I attended. The venue is one I’ve never attended, the Peres center for innovation. It’s on the Jaffa beach and you can literally see the waves hitting the beach from the main stage. Check out the photos below, you can literally see people on the beach in some of them. That’s a fantastic venue. The only downside is the distance from the center of Tel Aviv where I live. But that’s nothing compared to distances in the states… The event had 600+ registrations from over 80 organizations. This is the first Spring Tour outside of North America which is cool. The talks were in English which I like, but the Israeli accent is sometimes difficult to understand (yes I know). Unfortunately, I had to leave early because I had to pick up the kids. Before we proceed I want to say a couple of things about Twitter. Over the past month I and it's pretty great. There's even the which lists prominent community members on Mastodon. Foojay and interest is high. moved to Mastodon Java Bubble added its own instance I see no reason to stay on Twitter. It's toxic and getting more-so by the second. I still have my account and I have . So if you follow me there you won't miss anything. But I won't go there as often and will try not to post there. All the links in this post and future posts will refer to other networks whether LinkedIn or Mastodon. a bridge that tweets my Mastodon posts Juergen Hoeller – Introducing Spring Framework 6 Spring Framework 6 is a re-alignment of the framework. picked his works carefully, focusing on the conservative nature of Spring versions and compatibility to past versions. Spring Framework 5.3.x is very much JDK 8 based. It’s coupled to Java EE and the old javax namespace. It’s supported in open source until 2024 which means we need to make migration plans... Juergen With Spring Framework 6.x changes a few things: JDK 17+ Jakarta EE instead of Java EE and javax namespace AOT Support Virtual Threads (Loom) This will be the basis to Spring Boot 3.x. The biggest challenge I foresee is the JDK 17 requirement. That might challenge some migrations. As we make those migrations, we’ll probably containerize more. Ideally, that will make future migrations much easier. JDK 17 has some fantastic features though. Juergen focused a lot on the language features but there are some great GC improvements for containers which make the upgrade worthwhile in the enterprise. Migrating to the Jakarta API is a necessary evil since the packages for the old APIs are no longer updated. This is going to be a migration pain, but it’s unavoidable. This will require anyone who has a dependency on those APIs to move that code. The entire Java ecosystem switched to fast release cycles and updates to frameworks like Tomcat happen at a much faster rate. Juergen recommends skipping Jakarta EE 9 and going directly to 10. Spring Framework 6.1 will still support JDK 17, but it will also add support for JDK 21 which should be available by then. Jakarta EE 10 will be the preferred framework for that version. AOT is a tradeoff: extra build setup and less flexibility at runtime. Reduces startup time and memory footprint in production. GraalVM is the de-facto standard for native executables. It has a strong closed-world assumption, no runtime adaptations. Build time is very long. Personally I don’t think it’s that long as a guy who built an AOT JVM. OpenJDK static images (Project Leyden). Spring’s AOT strategy is aligning with Leyden’s JVM strategy. Starting from a warmed-up JVM image ( ) is also a promising option for fast Spring application bootstrap. First class support for CRaC is expected in Spring Framework 6.1. CRaC Project Loom is a preview feature in JDK 19 that enables high throughput for Java threads. They expect significant scalability benefit for database-driven web apps. It’s also a perfect fit for messaging and scheduling applications. This means WebFlux and reactive style is no longer primarily for scalability as Loom would provide that for “free”. Other features include fast bean property determination. Complete CGLIB fork with support for capturing generated classes. NIO based classpath scanning. First-class module scanning and further module system support (possibly) in 6.1. HTTP interface clients based on service. JDK HttpClient integration with WebClient but to me most interesting is the micrometer-based observability for RestTemplate and WebClient. @HttpExchange During the break I had time to talk to Oleg Šelajev and Juergen. The talk initially covered the future of CRaC. Jurgen was very optimistic about its chances as a future capability in the JVM and the chance of integrating it into a reasonable workflow. I asked him about the uptake of GraalVM and as of now the interest around the new versions focuses on other features. There’s excitement for GraalVM but it isn’t a killer feature. Yet. I have some thoughts on it which I will share at the end of the post. DaShaun Carter – Introducing Spring Boot 3.0 showed a live demo of building with GraalVM and contrasted the sub second startup time enabled by the native image in GraalVM. He then showed the RAM was a third of the full size JVM image. Another part of the demo showed the actuator works as expected which is nice since GraalVM native image doesn’t support the agent APIs in the current version. DaShaun The audience asked to see the size of the image which was half the size of the original image. The demo was good, but I’ve used GraalVM on Spring Boot in the past, so it wasn’t new to me. I asked about the uptake and traction they’re seeing for GraalVM native image. A lot of developers were waiting for Spring Boot to migrate to GraalVM and I’m curious if this is something they can already see in Spring Initializer stats. I wanted to know if the guys at Spring are seeing a flood of interest. DaShaun said he wouldn’t have made the trip if it wasn’t for GraalVM. But he invited me to talk later. I ended up speaking to Juergen and got the answer I “wanted”. After that he pointed at which I wasn’t aware of (or forgot). The scale of releases for November is amazing. https://calendar.spring.io/ Cora Iberkleid – Protect Your Microservices with Spring Cloud Gateway began her talk discussing some of the many use cases for a gateway. She emphasized that traditionally there were lots of use cases for a gateway. Spring cloud gateway is a lightweight approach to introduce a gateway that’s very approachable in the Spring ecosystem. They built it on the reactive stack and as a result it’s fast and has high throughput since it’s non-blocking. Cora The gateway uses predicates in handler mapping and can filter requests/responses. In the filters you can filter, apply rules, and process requests dynamically then apply filters to the response to provide flexibility to the client. Cora showed routing configuration in YAML and weighted routing to a web service. She then moved to circuit breaking using a request limiter. The request rate limiter is based on Redis and can throttle the amount of requests sent to an API with a replenish rate and burst capacity to block over-usage of an API. This is very useful to limit abuse and limit trial users. Until now everything was done with pure YAML configurations. The demo concluded with a custom route filter that changes the requests dynamically. Dr. David Syer – Running Untrusted Code in Spring Using WebAssembly There are many cases where we might want to run untrusted code. There are many ways to do that and as says WebAssembly is one of the best ways to do that. Although browsers support hosting WebAssembly, the focus of the talk is about server-side hosting. Dr. Syer WebAssembly is a polyglot environment which makes it very attractive for some cases. You can experiment with WASM directly in the Mozilla playground in MDN. In the talk he discussed the various compilers you can use to generate WASM from C compilers to AssemblyScript, etc. See https://github.com/dsyer/hello-as He provided an interesting link to a project for hosing WASM in Java: . https://github.com/kawamuray/wasmtime-java Exchanging data with WASM seems painful and a bit of a throwback to communicating and copying data back and forth. He provided two links of interest: https://github.com/dsyer/spring-wasm-demo https://github.com/dsyer/async-wasm After the talk I had time to talk a bit with Dr. Syer who was super nice. My fundamental problem is that I never “got” WASM. How is it better than running Java in a sandbox? The two use cases he mentioned were running untrusted code in embedded and edge computing. As a guy who worked in the mobile and embedded division at Sun/Oracle this stings a bit. I get why this is the place where we’re “at” but we had JVMs running in very constrained environments with MVM and for Java capabilities. It’s still around it just never got the traction that WASM is gaining. Another aspect is the Polyglot support. Being able to do that for C or Rust code. But that’s not as interesting to me and for most of the use cases I can think of. We obviously have good Polyglot options in the JVM, but mostly in higher level GC languages and not so much in languages like Rust or C. On the other hand, we have many other capabilities such as GC, deep native integration, elaborate memory model, etc. I’ve had this discussion with many smart people who see a lot of potential in WASM on the server. Notice that this isn’t about the browser where WASM has a valid use case. It might succeed simply because of mindshare, but as it stands right now, it seems that WASM is a couple of decades behind what we have in the JVM world. Finally Unfortunately, I had to pick up my kids from school and had to leave early so I didn’t have time to see the talk by about Test Containers or the many other . I did read the post on but I guess the talk would have been more interesting. Oleg Šelajev interesting talks Test Containers I need to go to more of these things. It seems I know more people when flying abroad to a conference than when visiting a conference in my country. As I mentioned before. I have some thoughts on why GraalVM isn’t taking over everything overnight. There are a few big reasons. It’s Work Moving to GraalVM requires a lot of work from the developers. Less so as time moves on. But still a lot of things need to change. Debugging is harder. We need to generate builds in CI and we can’t run them locally on some machines. It’s a pain. Adding the slow build process to the mix makes this even more painful. Dubious Benefit As developers, the memory and storage requirements we give are a given. DevOps have cost reduction incentives that can benefit from GraalVM but they can’t just integrate it. They need developers to do the work. In a corporate environment, the cloud waste is already astronomical. Sending a developer to migrate to a new VM so the DevOps team can get “cost saving credit”. That’s not something that the R&D management can get behind. The incentives in a corporate setting are problematic. Maybe the Spring team can arrange some viral marketing by helping twitter cut its cloud bill. I’m sure some of their microservices are Spring based. Observability While Spring Boot includes some monitoring tooling even with GraalVM. The level of observability on GraalVM is lower at the moment (no agent features). That alone might have been OK but coupled with everything else it could be a problem. We Don’t Use Serverless Java developers aren’t big on serverless. Over there GraalVM makes perfect sense and is already making great strides. But serverless isn’t as common in our community (rightly so IMHO) so the value for GraalVM isn’t as clear. To be clear. I’m very bullish on GraalVM personally. I think it will eventually enjoy significant market share traction and has many things going for it. But it will be a harder chasm to cross despite the obvious benefits. Originally published . here

SpringOne Tel Aviv World Tour Trip Report

Hello, everyone! My name is Ayina Egorova, and I work as an Agile Coach at inDrive. I’d like to share here some of my experiences working with teams without any sprints while leveraging the Kanban system. We hope that this article will be useful for team leaders and scrum masters, and any other change agents. Here you will learn how to quickly get your teamwork going without any sprints: find out where to start, what tools we use in the company, and what mistakes to avoid. Separately, we will look into an example of a STATIK workshop within our Localization Team. Introduction If you have a team that is tired of sprints and interested in implementing the Kanban method, the first thing you need to figure out is whether this style of work is a good fit for the team. In our work, we use an iterative-incremental process, i.e., an approach to organization that combines stage-by-stage execution and incremental product development (value creation). One example of such a framework is Scrum. It often happens, when a team’s work is based or focused on Scrum, that it delivers value in stages, using roles and events from the framework. At the beginning of each sprint, the team plans out work tasks, whereas at its end, it demonstrates the finished part of the product. Let’s not dwell here on the definition of Scrum. More details can be found in the official guide. The only thing you need to know is the criteria which can be discussed and checked together with the team. This will help you understand whether you and your stakeholders are comfortable working with the framework. Scrum criteria as the basis for teamwork: Product development can be broken down into meaningful stages with tangible business value at each stage. Operating in an environment of high uncertainty without knowing what practices and tools might work. Defining each sprint as an experiment — product-, team-specific, organizational. Having product hypotheses that involve the entire team. Understanding the metrics that are affected by the team. Organizing the team around one single goal for the sprint. Product tasks in the backlog prevail (80%+) over service tasks for other teams. A greater degree of autonomy for the team to make decisions and manage their backlog, i.e., what, when, why, and in what order should be developed. What else could be used? Recently, the Kanban method has been gaining popularity as a tool for managing intellectual work tasks and aligning processes within product teams. You can use all the practices of this method, some of them, or only one as the context may require. There is no firm definition of what constitutes the Kanban method, nor is there any cutoff point that determines whether the task is being processed according to the Kanban method. Read more about the relevant practices in this guide. Let’s move on to see how we apply Kanban practices in our product and service teams. Visualizing the workflow We use a digital board with different visual cues: marks, color codes, and templates. Limiting the work in process We set limits on the work in progress for each of the columns: individually, per team, and so on. Managing the flow of work We check the metrics that measure the workflow, set up the Kanban board, and each stage in the workflow. Making workflows explicit We create work agreements visible to all. Implementing feedback loops We show our work to stakeholders and gather feedback. Continuous improvement We conduct a retrospective analysis and identify areas for improvement Kanban can be applied to the following cases and needs: The need for visualizing invisible knowledge work. The need for workflow alignment. The need for eliminating bottlenecks for the workflow and employees. The need for value delivery to be predictable. Complex organizational conditions and the need to start somewhere right now. Clear stressors and motivators for change, e.g., dissatisfied management, customers, or teams. If the organization is not prepared to make an abrupt shift to agile practices (e.g., scaling frameworks) or widely used agile approaches are not a good fit for it, the Kanban method offers an alternative approach to organizational agility. What essential elements are required to start using Kanban? The Kanban method greatly increases the productivity of teams faced with a constant stream of new tasks. This system is used in a variety of areas from construction to IT. Even though it’s recommended to adopt all six core practices of Kanban, I have singled out visualizing the workflow and making workflows explicit as the two most valuable practices for beginners. To begin with, I will tell you about the first practice. Visualizing the workflow There are several options for visualizing the Kanban workflow. The most popular of these is a web-based task board. It's important to take into account what information you use on the Kanban board for decision making. Ideally, the Kanban cards should fit and meet the needs of the context. Example: If you need to track task completion times, the card should reflect the deadlines. Why visualization is required: To identify hidden work and visualize the full scope of tasks the team is working on. To display the blocking tasks that cannot be worked on. To figure out what types of work are being done. For example, different colored cards for tweaks and tech debt. To determine the amount of work at each stage and visualize the task assignees. Note that in today's world, a physical board is hardly ever used. Below I'll share with you what visualization tools we use at inDrive. Wrike is a convenient tool to create a space for the work of a particular division, as well as keep track of deadlines and assigned employees. You can create a color flag, prioritize tasks, make a checklist, or assign multiple employees to a task. Wrike. This tool is a great choice for teamwork in software development. You can use it to capture changes in code, build roadmaps, and generate detailed reports in the form of metrics and graphs, as well as to create a backlog list. Jira. Making process policies explicit You have to clearly establish the rules and make them transparent for each team member so as to minimize human-factor issues. They should be simple, clear, precisely articulated, flexible, and applicable in all settings. It’s a good idea to start off with simple rules and make improvements as needed. It's important to understand that the rules evolve and change during the process. Some examples of basic rules are described below: Arrangements for scheduled completion times. Readiness criteria (When can a task be considered completed?) Criteria for moving between statuses (When can a work item move from one status to another?) Prioritization criteria (Which tasks are considered priority tasks?) When do you need to add to the backlog? How long can work items stay in a column? Adding when selecting new tasks. The rules should be established and followed to enable the team to operate independently. Discussing and setting up agreements is part of the STATIK strategy. This approach is used to implement a Kanban system or find the current growth points. The following example is a step-by-step breakdown of the STATIK workshop within our Localization Team. Description of the system via STATIK What is this? The System Thinking Approach to Introducing Kanban (STATIK) is a strategy for making it easier to implement a Kanban system. This is a workshop in which you have to go through certain steps: assess project tasks, problems and expectations, priorities of tasks. Why is this needed? STATIK is conducted by different people: process, project and team managers who intend to change a process or implement a Kanban system. Typically, teams want to figure out how Kanban can affect the process and how to design their first Kanban system. The format. This is a workshop with facilitation and discussion arrangements that takes from one to several days. You don't have to do it all in one go, and it’s okay to break it down into short sessions of two hours each. It’s best to keep the intervals between sessions short, as the team must maintain concentration throughout the period, because this is the only way to achieve the desired results. STATIK includes eight key steps, but we skipped some of them and tweaked the workshop a bit to suit our own needs. Below, I will describe in detail how I conducted the workshop for our Localization Team. The goal was to achieve process transparency and find points of improvement. Workshop for our Localization Team Our Localization Team is responsible for translating and localizing the inDrive app into different languages. We split up this workshop into two 120-minute sessions, held one week apart, to make sure the entirety of the learning material is well retained. Below I will provide a step-by-step description of each stage along this journey. The first session included steps 1-4, and the second one included steps 5-7. Step One. What is STATIK? Duration: 10-15 minutes. The facilitator describes the context for the team: sets out the purpose of the workshop, explains the theory, and establishes the ground rules together with the team, if necessary. The format used in my case: What is STATIK? What is its purpose and what does it accomplish? When is this strategy used and what for? What are the steps to be taken? What will we do during the workshop? I established the ground rules for participants: participate, actively engage in discussion and activities, be present here and now. I emphasized the benefits of the workshop and why it was worth taking. Step Two. Ice-Breaker Duration: 10-15 minutes. Assignment: Upload a meme or a picture that answers the question: "What does our process look like?" It took 3-4 minutes to gather information, then every participant described their chosen option and shared what the processes within the team meant to them. Step Three. Sources of dissatisfaction Objective: Identify points of growth and raise awareness as to why the team needs to change. Duration: 20-25 minutes. Format: The team is seen as a boat being weighed down by an anchor. This makes it easier to seek out and get rid of the hidden sources of discontent. Divide the board into two sections: write internal sources on the left-hand side and external sources on the right-hand side. Assignment: Describe your team's internal sources of dissatisfaction. Describe your customer’s external sources of dissatisfaction. Note: It took us a long time to complete this assignment because we were describing external and internal sources of dissatisfaction separately. To save time, it’s best to fill out and discuss both columns at once. The problems collected were dealt with in more detail in a retrospective. Step Four. Demand and capability analysis Duration: 40 minutes. Objective: To assess how much the service is in demand and what types of input tasks are processed. Format: Identify the work by type. Assignment: Write on stickers the tasks the team is currently working on. Where does the workload come from? What is the customer asking for? For each type of work, we analyze the speed at which the task is input, the nature of the workload, and customer expectations. Note: The assignment was done with the team as a whole, without participants being divided into subgroups. Step Five. Life cycles of different types of work Duration: 35 minutes. Objective: To understand the stages of a task, as well as how we accumulate knowledge about it, and deliver value. Format: Put together a complete path of knowledge acquisition that would lead to a finished work-type item. In our case, to avoid time constraints, we chose two types: the most common and the longest. Assignment: 5 minutes — choose the longest and the most frequent types of work. 15 minutes — combine and break down into stages, as per the current practice. The current statuses can be opened. 10 minutes — how do you figure out the principle according to which the tasks are moved on to the next stage? Definition of Done, triggers for each status. Here it’s important to look not only at your team, but also to consider the time points before and after. For example, what is the status of the work task when it gets to us? Note: This stage of the workshop was run as a separate session. Before we got started, we spent 7-10 minutes reviewing the previous session and going back through the key training points. Step Six. Classes of services Duration: 20 minutes. Objective: To understand how we work with tasks Format: Joint teamwork, distribution of task types by class of service. Assignment: 10 minutes — ask the team to provide examples for all types of queries in their specific situations: Fast-track. Work tasks so urgent that they require immediate action and any other work has to be put aside. Fixed delivery date. Work tasks which, if not completed by a specific date, result in the imposition of a substantial penalty that is not commensurate to any benefit from early delivery. Standard. Work tasks to be performed as per the procedure agreed upon with the customer. 15 minutes — distribution of task types, class of service required. Note: What risks do you have associated with different types of queries? What is the cost of delay? Kanban system design Step Seven. Objective: To record the next steps, what data we will enter into the system and when. Format: To assess what we have achieved. Questions for discussion: What does a Kanban board with work tasks look like? Does it have enough space? How are the work tasks progressing within the interval from one project meeting to the next? Does the Kanban board make sense to those who will be using it? A good Kanban board ensures transparency. It’s important to improve the flow of work and change the board to make sure that the system itself is changed as a result. Note: We didn’t have enough time to go through this step together during the workshop. For this reason, I separately suggested further steps for improvement, and after the workshop, the team and I discussed what and when we would start implementing them. The conclusions and results Scrum is based on an iterative-incremental approach, a commitment to continuous learning, and adaptation to change. This strategy is most effective for small teams that create or improve a product in an uncertain environment. The Kanban method focuses on the continuous delivery of value. You can use all the practices of this method, some of them, or only one, as there is no firm definition of the Kanban method. Visualization as the backbone of Kanban helps you see the big picture and the individual parts that comprise it. STATIK is an awesome workshop that covers a sequence of actions to be implemented for launching a new Kanban system or improving your existing one. In the next part of the article, I'll tell you about how we assess work tasks and conduct events, and what metrics we monitor, as well as how we apply classes of service. A huge thank you to Daniil Korotkov for preparing this material and for sharing his expertise. I'll be happy to answer your questions in the comments :) Also Published Here

Using Kanban to Work With Teams Without Sprints

As humanity makes rapid strides to catch up with the ever-evolving expansive world of the web, the UAE is sprinting—with tangible evidence to show for it. Undoubtedly, the highly tech-advanced nation is determined to live its promise of becoming a leading player in Web 3.0. The journey kicked off in July with Dubai unveiling its , a vision expected to push Dubai into the list of the leading Metaverse Economies. Since then, the city has experienced a surge in virtual activities as the government, private firms, and start-ups scramble to find a footing in the Metaverse. Metaverse Strategy The Ground is Set While Dubai seems to be taking the lead, other nations are making giant strides in the same direction. Saudi Arabia, for instance, has set aside an over US$6.4bn kitty to kick start its Metaverse journey. The bounty will be invested in advanced technologies . like the Neom Tech and Digital Company The firm already has a footprint in the Metaverse, whereby they unveiled the XVRS in February this year. The one-of-its-kind project is a cognitive twin metaverse that allows visitors to experience a physical and virtual presence in one go. Multiple Moves in the Right Direction The UAE virtual space is filling up fast, with multiple projects taking off in the recent past. In fact, many of the thoughtful innovations have clinched slots in the world's first category. Taking the Lead Taking the lead in the financial sector is . It's the world's with sites on Sandbox and Decentraland. Kuwait-based Warba Bank first Islamic bank to launch into the Metaverse The is also from the UAE. Striving to become a leading digital telco, has a presence in the Metaverse. Similarly, the has a slot in cyberspace. first telco on the Metaverse Virgin Mobile Kuwait giant Etisalat Still, on setting the pace, the is Qatar University from UAE. Soon, the region will produce the , a . world's first university on the Metaverse first hospital in the Metaverse brain child of the Thumbay Group The Bottom-line Beyond the UAE's thunderous entry into the Metaverse lies a huge yet-to-exploited potential. Rob Gryn, the founder of Everdome, put it quite well, "People here want to be part of the latest trends, especially when it comes to technology and gaming. When people are excited about something, brands get excited too, which means they will make a move to invest in their metaverse presence. That will fuel the Web3 economy."

The UAE's Sprint Into the Metaverse

In the previous article, we looked at the . But how do we measure our velocity to know how long each sprint is going to take and plan ahead? Sprint Velocity Best Practices In this guide, we’re going to dive into: What is sprint velocity? What formulas you can use to measure it? 3 mistakes to avoid when measuring sprint velocity What Is Sprint Velocity? The Agile management framework is based around sprints — short periods of work, moving towards a specific goal. measures the amount of work your can complete within the average sprint. Sprint velocity scrum team There are several different ways to count sprint velocity. You could find the average number of , the average , or even the . The higher the score, the more your team is getting done. story points hours of work done number of ideal days Why Does Sprint Velocity Matter? When you create a roadmap for developing your product, it’s common to set a target date for each major stage. But how do you know what is achievable? Sprint velocity , and how many sprints it will take to reach bigger goals. In turn, this can inform your estimated delivery dates. helps you estimate what you can feasibly get done within each sprint Sprint velocity metrics are also very informative when it comes to productivity. By tracking the velocity of your team over time, you can or spending too much time comparing notes on the latest Wordle. see whether you are becoming more efficient How Do You Measure Sprint Velocity? While sprint velocity is based on data, it’s more of an estimate than a hard figure. To come up with a meaningful number, you need to track the amount of work done in at least five sprints. Then, you can plug your data into one of these sprint velocity formulas: 1) Sprint Velocity in Story Points Measuring sprint velocity via story points is a good idea, because these units take into account the complexity of work done, not just the time spent on the job. To find your sprint velocity, add up all the completed user stories within each sprint. Then, multiply this figure by the number of story points required for each user story: 5 user stories × 8 story points = 40 story points (Total) In this case, the team completed five user stories. Each of those user stories involved eight story points worth of work. To find your sprint velocity, repeat this process for multiple previous sprints and then find the average: Sprint 1: 36 story points Sprint 2: 40 story points Sprint 3: 38 story points 36 story points + 40 story points + 38 story points = 114 story points 114 story points ÷ 3 sprints = 38 story points/sprint (average) In this case, your sprint velocity is 38 story points per sprint on average. Not bad! 2) Sprint Velocity in Hours If you prefer to use a more traditional metric, you can just as easily calculate sprint velocity in hours. In this case, find the number of hours your team spent on each sprint: Sprint 1: 360 hours Sprint 2: 356 hours Sprint 3: 400 hours Then, add all your hours together and divide by the number of sprints to get your average sprint velocity: 360 hrs + 356 hrs + 400 hrs = 1,116 hours 1116 hours ÷ 3 sprints = 372 hours/sprint (average) For more granular statistics, you can perform the same calculation to find sprint velocity per story. 3) Sprint Velocity in Story Points and Ideal Days An alternative method for measuring sprint velocity is using ideal days. This option is , rather than the performance of your entire team. better suited to analyzing the performance of individuals The calculation for this metric builds on the one mentioned above. First, you need to find out how many hours were completed in each sprint. Next, you need to divide the number of hours of work completed by the number of hours in an ideal day. Sprint: 42 hours Ideal day: 8 hours 42 hrs ÷ 8 hrs = 5.25 ideal days Finally, we can add together the number of ideal days completed in all the sprints, and divide this figure by the number of sprints. Sprint 1: 5.25 ideal days Sprint 2: 4.5 ideal days Sprint 3: 6 ideal days 5.25 ideal days + 4.5 ideal days + 6 ideal days = 15.75 ideal days 15.75 ideal days ÷ 3 sprints = 5.25 ideal days/sprint (average) If you don’t want to run through the numbers yourself you can plug your data into this . free sprint velocity calculator What Is the Best Way to Visualise Sprint Velocity? So far, we have looked at how you can estimate your sprint velocity from recent sprints. However, this figure only becomes truly useful when you have something to compare it with. Here are two common ways that Scrum teams track their sprint velocity over time: 1) Sprint Velocity Chart Perhaps the easiest way to track your productivity is with a . This is a simple graph that shows how your average changes over time. sprint velocity chart To add some extra context, you can also include the expected amount of work for each sprint. This will reveal whether your team is consistently hitting expectations, or falling short. It will also give you a sense of how to adjust your future estimated workloads. 2) Sprint Velocity Burndown Charts When you’re on a tight deadline, you might want to keep an extra close eye on your sprint velocity. show you how much work you have completed, how much work is still outstanding, and how much time you have left to get it done. Burndown charts While this option is a little more complicated to set up, it provides a really helpful overview for project managers. In one glance, they can clearly see if the team is on schedule or lagging behind. Image credit: Wikipedia 3 mistakes to avoid when measuring sprint velocity 1) Not taking technical debt into account is the silent velocity killer. To measure sprint velocity, you need to ensure that you know your codebase problems well. Technical debt Track and prioritize your technical debt regularly to see which parts of the code can be problematic and will affect your team velocity. The easiest way to do it is to use the Stepsize and extensions. They’ll help your Engineers see issues in the codebase and report them directly from their editor reducing context switching. VSCode JetBrains 2) Using velocity to measure the performance of a team The main goal of measuring sprint velocity is to plan future sprints and report estimations, not measuring your team performance. As says, “When a measure becomes a target, it ceases to be a good measure.” So don’t compare your teams’ velocity and find other . Goodhart’s metrics for your team performance 3) Focusing on the numbers too much Make the quality of your code your main focus. When you feel like you should be getting more done in the week, a natural reaction might be to increase your working hours. While this may work for an individual sprint, it’s not going to provide long-term improvement. It can also lead to burnout in your team. Try to . Encourage your team to get things right the first time, even if it takes a little longer. In the long run, this will actually save a lot of rework and improve your . focus on quality code quality Take Control of Your Sprint Velocity As we have discovered, sprint velocity is an important metric. There are many different ways to measure it, and even more ways to improve it. Here’s what we have learned: Sprint velocity is a good measure of productivity You can measure it in story points, hours, or ideal days It’s best tracked using regular charts or burndown charts To improve your sprint velocity, focus on quality and not quantity Follow these steps, and you might be surprised just how much your team can get done in your next sprint! Also Published Here

Measuring Sprint Velocity

From the traditional Waterfall model to more iterative approaches like Agile and DevOps, software testing is constantly evolving. And while teams have worked their way to deliver quality at speed, there seems to be something holding them back. Read on to learn about in-sprint automation and why it’s the key to moving at DevOps speed. The Time Lag Between Dev and QA N-1 sprint is a common approach in which testing activities start at least one sprint behind the development process, and new functionalities are tested only when they become relatively stable. For many automation testing frameworks like Selenium WebDriver, creating and executing tests takes a considerable amount of time. Therefore, testing new functionality after some degree of product readiness is reasonable. But N-1 sprints also bring about the time lag between testing and developing. That is, QAs often have to wait for one (or even two months) before actually exploring new functionality. And when they have something to play with, they struggle to keep up with the development pace. If we think of it that way, N-1 sprints are more or less the replica of the traditional Waterfall model. Breaking Teams’ Silos With In Sprint Automation To break free from the siloed approach of N-1 sprint automation and bring team collaboration to a new level, meet in-sprint automation. Instead of designating Devs and QAs into different sprints, in-sprint automation needles the core functions and engages the entire testing process (creation, implementation, execution, and reporting) all together in one sprint. This one-sprint window brings forth: In-sprint breaks down the invisible siloes between Dev and Ops and ensures everyone in the team progresses simultaneously. Cross-functional collaboration: In sprint introduces the opportunity to detect and fix bugs earlier in the as the automated tests will be ready at roughly the same time as ‘code complete.’ Only a handful of manual tests should be required. Earlier bug detection: SDLC Test cycles will become significantly shorter, and test coverage can be maximized right from the first build. Shorter release cycles and maximized test coverage: Roadblocks to In Sprint Automation If moving towards Agile and DevOps culture is your goal, shifting from N-1 sprint to in-sprint automation is one first step to get there. However, on the path to in-sprint automation, your team might encounter some roadblocks, one of which is handling . last-minute changes in test requirements In Agile teams, testers can use Acceptance Criteria as test requirements. Acceptance Criteria are part of a user story—a brief explanation of the customer-relevant functionality. However, the initial understanding of users and software in development might be incomplete. That’s why when teams learn something new about their users, product owners, developers, and other members get together to discuss and “upgrade” the existing user stories. Those upgrades might lead to test requirements being changed at the very last minute. And testers are left with two options: modifying test cases or starting from scratch. As discussed earlier, creating and running test cases for many testing frameworks is not an express delivery service, and the whole process might take as long as one to two weeks. And it’s not entirely due to the lack of technical expertise, either. Programming background and experience might play a role in modifying test cases within time constraints. But that tactic won’t compensate for the in any given tool or framework. bulky test creation and execution process So suppose teams use frameworks like Selenium WebDriver anyway. Chances are, they will eventually have to discard the entire testing progress of user stories and carry them over to the next sprint. What happens next? Their confidence wanes out over time; testing falls far behind the development pace; they have to circle back to N-1 sprints eventually. Admittedly, in sprint automation is not a one-size-fits-all solution, especially for teams with bulky and inflexible frameworks. Going Fast and Lightweight With Katalon Recorder To avoid those roadblocks to in-sprint automation, besides team skills and collaboration, finding a suitable automation solution should be your next action item. As a robust automated testing solution, Katalon Recorder provides a fast and lightweight option to achieve in-sprint automation: Katalon Recorder supports script-less and fast automation with Record and Playback so that teams can start testing right away and progress in parallel with the development pace. Low-code automation: Advanced features like Self-healing, Global Variables, and Dynamic Test Suites help testers reduce the time, effort, and risks to shorten their test cycles and maximize test coverage. Shorter release cycles: Thanks to its built-in test orchestration platform – – Recorder provides quick test reporting and analytics for better communication and cross-team collaboration. Cross-functional collaboration: Katalon TestOps Recorder enables flexible test exporting options to other popular frameworks like Katalon Studio or Selenium WebDriver. Users can also execute imported tests with minimal effort as Recorder is also compatible with popular programming languages like C#, Java, Ruby, Robot Framework, etc. Scalable pathways: Start In-sprint on a Good Note To achieve in sprint automation, we have to take into consideration many factors, and picking a suitable test automation framework is among the most critical ones. In sprint automation might not be an easy call, but the benefits will be well worth the hardships.

In-Sprint Automation: How to Increase Software Testing Speed

What's your startup called? And in a sentence or two, what does it do? Sendify – shipping for everybody else. What is the origin story? Sendify is a fast-growing SaaS Enabled Marketplace that offers small businesses a simple and cost-effective shipping solution - so that less time and money is spent on logistics and more on running a company. Shipping Management platforms have previously been developed for larger companies, which has left the small and medium-sized enterprises without competitive shipping solutions that are targeting the small businesses’ logistics needs and their price sensitivity. In other words, there has been a huge segment that has been overlooked - until now. What do you love about your team, and why are you the ones to solve this problem? People on the team are handpicked for who they are; they are genuinely nice individuals with a big passion for building something challenging together. Having a stable foundation and tireless grit for challenging the industry are the key ingredients. If you weren’t building your startup, what would you be doing? Building another startup. At the moment, how do you measure success? What are your core metrics? Success means providing small businesses with the smartest shipping solution out there. Hence, seeing our base of happy customers grow, from all over the world, is our main metric. What’s most exciting about your traction to date? I would probably steer this insight to customer insights; we see the exact same need of our customers in the markets we are present in. This is the opportunity that we are going after. What technologies are you currently most excited about, and most worried about? And why? We are excited about the SaaS Enabled Marketplace that we have created and how we can help businesses with our unique technology. The aggregated buying power of the many small businesses that book their shipping through Sendify, enables Sendify to generate marketing leading margins. In addition, Sendify runs subscription incomes through the system from larger companies, as well as other incomes such as insurances, ultimately enabling a hybrid revenue model. Altogether, Sendify has developed an income-generated machine that combines transactional and subscription incomes, at the same time as Sendify creates value for both ends of the marketplace. What advice would you give to the 21-year-old version of yourself? Don’t take things too seriously. It’s not a sprint, it’s a marathon. Optimize for the marathon. What is something surprising you've learned this year that your contemporaries would benefit from knowing? On the same note as above - it comes with age I guess ;) Vote for Sendify as the . startup of the year, Gothenburg

'It's Not a Sprint, It's a Marathon': Fredrik Edeland, CEO of Sendify

There are plenty of posts that tell you that sprint planning should include things like shaking hands, making pledges, and a team song (I wish I were joking). This is not one of them. Nor am I advocating for you to buy into any particular school of thought (i.e. Scrum vs Agile) or suggesting that you need to sign up to someone’s downloadable program for $XX, the author of which will haunt your inbox forever. Instead, I want to offer practical strategies to make planning a Sprint less painful so that you feel organized rather than overwhelmed and have achievable goals rather than just another staggering list of to-dos. A successful Sprint should leave you feeling like you’ve worked on things that are important and worthy of your time. What is the purpose of a sprint planning meeting? The purpose of sprint planning is to define what can be completed during the next sprint and decide how the work will get done and by who. This included reviewing any leftover tasks from the last sprint and creating a plan of action for these as appropriate. Sprint planning attendees Scrum Master/Sprint leader The Scrum Master is responsible for setting up the infrastructure for the sprint planning meeting (zoom meeting/room booking, etc.) and managing timekeeping during the meeting to ensure that everyone is aligned on the goals of the upcoming sprint. Side note: I am using this term as I understand an agreed-upon alternative is yet to be decided upon in the world of Scrum. Product Owner The product owner arguably does the bulk of the pre-Sprint meeting work. They prepare the list of product backlogs to choose to work on/prioritize during the sprint and facilitate discussion on the priorities of the sprint. Development team These are the vital people that will be doing the work during the sprint - think devs, designers, test engineers, etc. Before the meeting Sprint planning is about gathering the necessary people together to determine the product development goal and work you will do in your upcoming sprint. But before you get to a planning meeting, there’s a reasonable amount of prep you need to do to organize. Bring the backlog to order The Product Owner is responsible for collating and organizing all backlog items that could be worked on during the sprint and is typically referred to as . They may do this alone or at a pre-meeting before the planning and aim to break tasks down into actionable items. backlog grooming Be clear on team velocity and capacity Consider the amount of work that participants can successfully complete during a sprint. Consider the achievements of previous sprints as a way to measure team velocity. What tools and skills are needed to achieve the work? Who is available to work on the sprint? Define your sprint goal Determine the aim of your sprint and what you want to have achieved at its end. Writing this down is helpful to offer clarity to not only team members but other stakeholders outside of the sprint also. Make an agenda for your sprint planning meeting The common view is that planning a 2-week sprint should take about four hours. Map out the agenda of the meeting accordingly. There are plenty of sprint planning templates around if you don’t have one already, for example: Smart sheet Atlassian Fellow Planio What about technical debt and sprint planning? Stefan Wolfers that there is an inherent contradiction in ownership and decision-making in a Scrum mentality regarding . He asks: asserts technical debt “If technical debt is the plague of our industry, why isn’t the Scrum Guide addressing the question of who is responsibly dealing with it? To make things worse, if the Product Owner’s responsibility is to maximize the value customers derive from the Development Team’s work. The Development Team’s responsibility is to deliver a product Increment (at least) at the end of the sprint adhering to the definition of “Done,” aren’t those two responsibilities possibly causing a conflict of interest?” It is vital to make paying down technical debt - including tasks such as code refactoring and bug fixing - a priority of every single sprint. Bug fixing feels like a never-ending loop if you have a high level of debt, and a sprint can unearth even more bugs. Focus on the bugs you have committed to deal with and add those you find (unless incredibly urgent) to the bug backlog for your next sprint. Your team also needs an agreed-upon definition of Done to avoid more technical debt sneaking in. How to include technical debt into your sprint? Instead of having a dedicated technical debt sprint every quarter try a more sustainable approach of spending 10-30% of every sprint dealing with the most important technical debt. It’ll help you prioritize the tech debt that's in the way of upcoming features on the product roadmap. (If you want to learn how a modern team at Snyk has achieved it, check out .) this case study Here are 3 steps that’ll help you incorporate technical work into your usual sprints: Make technical debt visible Start with highlighting, bookmarking, and creating technical debt issues. You can easily do that with the Stepsize VS Code or JetBrains extensions. Determine the business impact of each debt item If you have a difficult time convincing your management to work on technical debt, try focusing on the business impact instead of technical problems. E.g. mention how fixing this debt will reduce the number of support tickets or help you reduce the time-to-market. Bring it to your sprint planning meeting Once you've created technical debt issues and described their business impact, bring it up during your next sprint planning to discuss with the team. Deciding what technical debt to focus on in your code sprint is comparable to and you can also use prioritization features. prioritizing tasks in your product backlog Stepsize’s Remote work planning How we work is constantly changing. Many traditional Sprint planners talk about whiteboards (digital or otherwise) and getting everyone together in the same room. We know that’s often not just practical with distributed teams. Where possible, avoid a hybrid model where a chunk of the team is together and the rest distributed unless you have good practice doing this successfully. Otherwise, what tends to happen is that those who are physically present make group decisions, and the input of remote people is more of an afterthought. Online tools (see upcoming article) are critical to ensure that everyone gets an equal seat at the meeting. Be especially aware that remote meetings are more draining than in-person meetings and plan accordingly with breaks and keeping things focused. Reward your team Sprints are more pleasurable if there’s something to look forward to - if budget allows, consider getting some catering in or delivery orders to people’s homes for remote workers to celebrate the end of a sprint. Even if a sprint is commonplace in your company, everyone likes thanks. And don’t forget to celebrate the tech debt heroes who have done behind-the-scenes work! Previously published at https://www.stepsize.com/blog/how-to-run-an-effective-sprint-planning-meeting

Effective Sprint Planning: How To Not Get Overwhelmed By Technical Debt 

This week community members uncovered ways to properly plan product sprints. Check it out! Product School Slack's Sudeep Aug 1, 2021, 6:48 PM Hi there, is there a way to do the sprint planning without doing the effort estimate for each ticket ? Don't you guys think that effort estimation is very time taking and tedious work ? Daniel Aug 1, 2021, 11:47 PM One thing to keep in mind is that Story Points are meant to be a measure of complexity, not a measure of effort. A junior dev and a senior dev will have different levels of effort for the same item. The complexity remains the same. You can simply stop estimating the complexity. It's useless. At the point in time where an item is in your backlog, and you feel confident that it's been descoped and broken down as small as possible - it doesnt matter what kind of complexity it attracts. If it's the most important thing to drive business impact at that time, you damn well are going to do it. 🤔 1 There has been a growing No Estimates movement for quite a few years now. Do a bit of googling, and feel comfortable in dropping estimation from your rituals. Priortize on impact and if use your gut when planning. If it feels 'too much' in a spint, then don't add so much. If you complete the work committed in the sprint early, simply take the next item in the backlog. 🤔 1 Yuting Chu Aug 2, 2021, 2:59 AM Hi , interesting insight. Can you post a link to the source where story points are meant to be a measure of complexity and not effort? I have the book User Stories Applied - is it in there? How are you doing the story point estimate? It’s not meant to be time consuming or tedious mark Aug 2, 2021, 5:26 AM To add to Daniel- it’s complexity, effort, and unknowns (but most people think it’s time) I once had a data scientist ask me, why the weight of two tasks at 1 and 2 points isn’t equal to that of 3.. interesting think to think on. Time is something we’re all taught so it’s easy to think that quickly. Thought the purpose of using points is to measure the tasks being handed out so we don’t hand out too much. Ideally we’d get everything done but really it’s to say this is a “big” task cuz it’s complex or there’s a lot we don’t know etc or a small and simple task because we know what we need to do and it’s not a high effort (etc) ✅ 1 👍 1 Uday Vyas Aug 2, 2021, 7:36 AM Hi Sudeep,  Completely agree with Daniel and Mar. So,  in my exp. as a Project Manager, I have followed the following: We have Architect or Sr. Lead take a call on Complexity. The complexity is rated in terms of t-shirt sizing and same is used to extract hrs. required Sample of same based on our historical dev. exp is: ..Not Sure how to add tables here.. Uday Vyas Aug 2, 2021, 7:40 AM Did you enjoy this conversation? Join the #1 Slack Community For Product Managers Join our private community to network with over 90,000 PMs. Explore our industry-leading Slack channel, and discover for yourself how it became the most expansive community of Product Management across the world: Weekly AMAs: Every week we host ‘Ask Me Anything’ sessions with top PMs in the industry. This open Q&A forum gives you the most impactful insider access to all your Product questions. Resources: Specific and dedicated channels for all of the most important topics in product: #05_ask-for-help, #07_resume-review, #08_job-portal, #10_feedback-n-surveys, #11_product-launches, and more! Careers: Searching for a career change? Or looking to get your foot in the Product door? Our Slack channel has daily job openings in Product that are posted by Product leaders looking for new qualified PMs to join their teams. Network: Connect and network with Product people from your city or country in our local channels (#local_sanfrancisco, #local_europe, #local_singapore, and more!) Join here https://productschool.com/slack-community/ To learn more about Slogging, or to partner with Hackernoon and add the Slogging Beta app to your Slack community and create beautifully crafted & curated Hackernoon drafts, visit Slogging.com

Sprint Planning Minus Estimation Efforts

Manchester striker breaks down conservative government resistance to feeding the hungry with Twitter onslaught. On October 26th, Reuters and the Guardian reported British Prime Minister Boris Johnson surrendered to the superior endurance and determination of Manchester United footballer Marcus Rashford and agreed to . support free school meals For a man only 22 years old, Marcus has an impressive record of activism around hunger: * In October 2019, Rashford partnered with Selfridges, a chain of high-end department stores, to launch the “ ” campaign to provide essential items for the homeless during the holidays. In the Box * In March 2020, Rashford partnered with charitable organization to deliver meals to kids in the Greater Manchester area who no longer received free school meals during the COVID-19 pandemic lockdown. Fareshare * On 15 June, Rashford wrote an open letter to the UK government calling on them to end UK child poverty and causing the government to announce the extension of free school meals for children during the summer holidays. This past summer, the Holiday Activity and Food (HAF) program was piloted with the goal of ensuring children in the UK are provided with at least one free meal a day outside school time. When Conservative Party lawmakers voted down a plan to extend the HAF program and provide meals for kids over Christmas, Marcus Rashford launched a one-man information campaign to pressure Johnson to extend the HAF program and provide meals for . 1.3 million children in the UK Rashford, who has 3.7 million Twitter followers, used the platform using the hashtag #ENDCHILDFOODPOVERTY to call on local businesses to pledge free lunches for kids over the holidays. When Rashford received hundreds of responses, he starting retweeting all the local businesses that volunteered to provide free lunches for kids. Tweet showing the geotagged locations of businesses that pledged to provide food for hungry kids. The fact that UK businesses are ready to fill the gap where the government won’t take action and feed hungry children became an embarrassment for Johnson, but Rashford amplified his message with the impressive athleticism brought to tweeting. According to a recent by Import.io, Rashford tweeted in “sprints”: blog article * Rashford tweeted 218 times in less than 24 hours.Rashford apparently took a 7-hour break for sleep, so deducting that time he averaged 14 tweets per hour — nearly 1 tweet every 4 minutes.Rashford peaked toward the end of his initial 24-hour session reaching speeds of 1 tweet every 1.5 minutes. * Marcus used his popularity to successfully show he could crowdsource the effort if needed — and showed that public sentiment was in support of the program. * On Monday, Johnson’s government relented and supported the extension of the free meals program for children through the holidays. A national version of the scheme is estimated to cost 200 million pounds ($260 million) a year. Rashford has confirmed in interviews that seeing his own mother struggle to feed her kids is part of the inspiration for his ongoing activism. According to the Child Poverty Action Group, more than (nearly 30%) live in poverty and the trend seems to be getting worse. four million children, Rashford urged followers to donate to this week and has a link to the organization’s website . FareShare said Rashford’s efforts have helped raise donations to provide over and families. FareShare in his Twitter bio 4.2 million meals for children

Boris Johnson Surrenders to Marcus Rashford's Amazing Twitter Sprints

Those of us in the business of selling secondhand mobile phones have been closely following the new cell phone trends and developments in 2020. However, one piece of news that has gotten a bit buried amid it all is the T-Mobile/Sprint merger. T-Mobile successfully acquired Sprint on April 1. As you may have noticed, it’s been somewhat of a quiet summer as far as the merger goes—but that’s about to change. Quick Takes: Where Things Stand with the Merger Today T-Mobile officially folded the Sprint brand under its flagship banner on August 2. We may be seeing some ripples finally take form in the industry once some key “separation dates” get here. The big, obvious development impacting both resellers and customers is that we’re down to just three major cell carriers in the United States (Verizon, AT&T, and T-Mobile). What should we expect down the pipeline as a merger that’s mostly been on paper up until now takes shape in real life? Let's explore some key speculation points related to the T-Mobile/Sprint merger with a focus on the impact the newly formed conglomerate could have on secondhand mobile phones. There are some interesting things to look at, specifically in terms of pre-2020 5G devices being traded in prematurely in some markets. Why Are T-Mobile and Sprint Merging? While there are many peripheral advantages to merging for both carriers, resellers should make no mistake about the fact that there is one main objective behind the T-Mobile/Sprint merger: This conglomerate will be highly focused on bringing 5G to more places. In fact, the partnership’s ability to dominate in the 5G market hinges specifically on a strategy of bringing 5G to rural markets faster than anyone else can. T-Mobile needed Sprint under its tent due to Sprint’s well-known, long-standing relationships with the nation’s rural carriers. We’re potentially looking at a future where T-Mobile will be pushing for every customer to be a 5G customer. An expanded 5G network across rural parts of the country means that more cell customers may be eager to trade in existing devices for 5G devices. This could increase the supply of newer, non-5G devices on the resale market as T-Mobile advances its plans. Popular Opinion: It Will Be a While Before Customers Feel the Merger Deeply It looks like T-Mobile is taking every measure necessary to make sure current Sprint customers can enjoy a changeover that’s as non-abrupt as possible. For now, both Sprint and T-Mobile customers can keep doing exactly what they’re doing, including visiting the same brick-and-mortar stores that have served them as their cellphone homebase thus far. In addition, all online account management for Sprint customers will be exactly the same for the time being. The long-term goal is to transition all Sprint customers over to the T-Mobile network before creating a combined, supercharged network. T-Mobile has also promised to preserve pricing for three years. While customers will see branding updates across their accounts in the upcoming months, they won’t see any bill increases or changes until 2023. In addition to folding millions of Sprint customers into its brand, T-Mobile is also aggressively trying to court “switchers” from the nation’s two major carriers using an aggressive trade-in offer. T-Mobile will pay off the remaining device payments or service contracts for all customers who make the switch from Verizon or AT&T. The carrier will be handing out up to $650 per line via trade-in credits and virtual prepaid cards whenever a customer trades in an existing phone for a new one. This will have an obvious impact on the trade-in market if customers bite. This is Where It Gets Interesting for the Resale Market One of the more complicated aspects of the merger of T-Mobile and Sprint is that they use different technologies to power their 2G networks. While T-Mobile uses GSM, Sprint uses CDMA. As you may know, the big difference is that CDMA phones generally don’t use SIM cards like GSM phones do unless they’re LTE-enabled devices. The speculation now is that T-Mobile will choose GSM as it makes the pivot to unify the entire conglomerate to a single form of technology. This means that current Sprint customers going along for the ride with T-Mobile will find themselves with devices that are not compatible with their networks in the not-so-distant future. As a result, these customers will need to upgrade to new devices to be able to get network coverage. Yes, T-Mobile is making a big show of saying that nothing is changing for Sprint customers; however, it seems inevitable that the merger will cause a large portion of current Sprint customers to outgrow their devices prematurely. We’ll also see something of a device limbo for millions of existing Sprint customers with 5G-compatible devices from now until the three-year merger process is completed in 2023. We expect that any Sprint 5G phone that came out before the Galaxy S20 will be rendered outdated because Sprint 5G phones released in 2019 to enable access to T-Mobile’s 5G network. The affected devices include the OnePlus 7 Pro 5G, Samsung Galaxy S10 5G, and the LG V50 ThinQ 5G. Those devices will still be capable of tapping into Sprint’s 4G network, but only where it’s still available. will not be getting updates T-Mobile has tried to smooth the rough patch by offering discounted 18-month leases on Galaxy S20 5G phones to replace the soon-to-be outdated devices. This is interesting for resellers because even fairly new 5G phones from before the February 2020 release date of the S20 may be appearing in the resale market much earlier than would be expected without the Sprint/T-Mobile merger. We can also look ahead to potentially seeing post-lease S20 5G phones hitting the market 18 months from now (potentially February 2022). Speculating on How the Merged Companies Will Handle Resale of Used Devices T-Mobile isn’t giving any behind-the-scenes looks at how it’s handling the resale of traded Sprint devices. That means we don’t yet know if they will continue to sell their used devices separately or consolidate used phone supply. However, it’s pretty clear that the two brands will have a consolidated used phone supply by at least the 2023 deadline for the merger being fully complete. The one thing that does seem certain is that whatever channel T-Mobile decides to use to deposit Sprint devices that are will see more CDMA and pre-2020 5G devices. traded in Final Takeaways on the T-Mobile/Sprint Merger The T-Mobile/Sprint merger will affect 5G device traffic for resellers. Existing Sprint customers who would have held onto their devices may create an influx of pre-2020 devices much sooner than expected. In addition, we may see more CDMA than GSM devices traded in than usual as Sprint customers adjust to T-Mobile’s network. Sources Used: https://www.cnet.com/news/t-mobile-to-redeploy-sprints-midband-5g-spectrum-in-new-york-in-may/ https://www.androidpolice.com/2020/07/03/t-mobile-confirms-its-going-to-brick-5g-on-most-sprint-5g-phones-post-merger/ https://secure.sprintbuyback.com/bbt/ https://www.twice.com/blog/potential-effects-of-the-t-mobile-and-sprint-merger-on-the-wireless-industry https://www.cnbc.com/2018/04/30/how-would-a-t-mobile-sprint-merger-affect-your-cellphone-bill.html https://www.cnet.com/news/t-mobile-and-sprint-are-one-what-you-need-to-know-about-the-mobile-mega-merger/#:~:text=After%20nearly%20two%20years%20of,fourth%2Dlargest%20national%20wireless%20carriers. https://www.t-mobile.com/news/press/t-mobile-guarantees-industrys-best-trade-in https://www.wired.com/story/t-mobile-sprint-merger-guide/ https://www.pcmag.com/news/what-the-sprintt-mobile-merger-means-for-sprint-customers

Stories, News & Mentions about SPRINTO

Sprinto’s Stories on HackerNoon