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

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

Sprinto

sprinto.com

201-500 employees

Since 2020

COMPANY RANKING

SPRINTO

EVERGREEN INDEX #9360

Sprinto WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

Sprinto

sprinto.com

201-500 employees

Since 2020

COMPANY RANKING

SPRINTO

EVERGREEN INDEX #9360

RELATED COMPANIESRANK

STORIES ABOUT SPRINTO

Sprinto WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!