DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Agile Zone is presented by the following partner

Agile

The Agile methodology is a project management approach that breaks larger projects into several phases. It is a process of planning, executing, and evaluating with stakeholders. Our resources provide information on processes and tools, documentation, customer collaboration, and adjustments to make when planning meetings.

icon
Latest Refcards and Trend Reports
Trend Report
DevOps
DevOps
Refcard #266
Agile Patterns
Agile Patterns
Refcard #093
Lean Software Development
Lean Software Development

DZone's Featured Agile Resources

Jira Best Practices From Experts

Jira Best Practices From Experts

By Oleksandr Siryi
Railsware is an engineer-led company with a vast portfolio of building projects for companies, so when talking about Jira best practices for developers, we speak from experience. Why Do People Love Jira? Jira is by no means perfect. It certainly has its downsides and drawbacks. For instance, it is a behemoth of a product and, as such, is pretty slow when it comes to updates or additions of new functionality. Some developers also say that Jira goes against certain agile principles because—when in the wrong hands—it can promote fixation on due dates rather than delivery of product value. Getting lost in layers and levels of several boards can, indeed, disconnect people by overcomplicating things. Still, it is among the preferred project management tools among software development teams. Why is that? Permissions: Teams, especially bigger ones, work with many different experts and stakeholders, besides the core team itself. So, setting up the right access to information is crucial. Roadmaps and epics: Jira is great for organizing your project on all levels. On the highest level, you have a roadmap with a timeline. Then, you have epics that group tasks by features or feature versions. Inside each epic, you create tickets for implementation. Customization: This is Jira’s strongest point. You can customize virtually anything: Fields for your JIRA tickets. UI of your tickets, boards, roadmaps, etc. Notifications. Workflows: Each project may require its own workflow and set of statuses per ticket, e.g., some projects have staging server and QA testing on it and some don’t. Search is unrivalled (if you know SQL aka JQL in Jira): Finding something that would have been lost to history in a different project management tool is a matter of knowing JQL in Jira. The ability to add labels using keywords makes the aforementioned search and analysis even simpler. Automation: The ability to automate many actions is among the greatest and most underestimated strengths of Jira: You can create custom flows where tickets will create temporary assignees (like the back and forth between development and QA). You can make the issue fall into certain columns on the board based on its content. Move issues to “in progress” from “todo” when there’s a related commit. Post the list of released tickets to Slack as a part of release notes. Integrations and third party apps: Github, Bitbucket, and Slack are among the most prominent Jira integrations, and for good reasons. Creating a Jira ticket from a message, for example, is quite handy at times. The Atlassian Marketplace broadens your reach even further with thousands of add-ons and applications. Broad application: Jira is suitable for both iterative and non-iterative development processes for IT and non-IT teams. Jira Best Practices Let’s dive into the nitty-gritty of Jira best practices for multiple projects or for a single one. Define Your Goals and Users Jira, being as flexible as it is, can be used in a wide manner of ways. For instance, you can primarily rely on status checking throughout the duration of your sprint, or you can use it as a project management tool on a higher level (a tool for business people to keep tabs on the development process). Define your team and goals. Now that you have a clear understanding of why, let’s talk about the “who.” Who will be the primary Jira user? And will they be using it to: Track the progress on certain tickets to know where and when to contribute? Use it as a guide to learn more about the project? As a tool for tracking time for invoicing clients, performance for internal, data-driven decision making, or both? Is it a means of collaborating, sharing, and spreading knowledge across several teams involved in the development of the product? The answers to the above questions should help you define the team and goals in the context of using Jira. Integrations, Third-Party APIs, and Plugins Jira is a behemoth of a project management platform. And, like all behemoths, it is somewhat slow and clunky when it comes to moving forward. If there’s some functionality you feel is missing from the app—don’t shy away from the marketplace. There’s probably a solution for your pain already out there. Our team, for instance, relies on a third-party tool to create a series of internal processes and enhance fruitful collaboration. You can use ScriptRunner to create automation that’s a bit more intricate than what comes out of the box. Or you can use BigGantt to visualize the progress in a friendly drag-and-drop interface. Don’t shy away from combining the tools you use into a singular flow. An integration between Trello and Jira, for instance, can help several teams—like marketing and development—stay on the same page. Use Checklists in Tickets Having a checklist integrated into your Jira issues can help guide a culture that’s centered around structured and organized work as well as transparency and clarity to everyone. Our Smart Checklist for Jira offers even more benefits: You have a plan: Often times it’s hard to start a feature implementation, and without a plan, you can go in circles for a long time. Having mental peace: Working item by item is much more calm and productive than dealing with the unknown. Visibility of your work: If everyone sees the checklist progress, you are all on the same page. Getting help: If your progress is visible, colleagues can give you advice on the plan itself and the items that are challenging you. Prioritization: Once you have the items list, you can decide with your team what goes into v1, and what can be easily done later. You can use checklists as templates for recurring processes: Definition Done, Acceptance Criteria, onboarding and service desk tickets, etc., are prime candidates for automation. Moreover, you can automatically add checklists to your Jira workflow based on certain triggers like the content of an issue or workflow setup. To learn more, watch our YouTube video: “How to use Smart Checklist for Jira.” Less Is More Information is undoubtedly the key to success. That said, in the case of a Jira issue, awareness is key. What we’ve noticed over our time of experimenting with Jira is that adding more info that is either unnecessary or irrelevant seems to introduce more confusion than clarity into the process. Note: We don’t mean that Jira shouldn’t be used for knowledge transferring. If some information (links to documentation, your internal processes, etc.) is critical to the completion of a task—share it inside the task. Just use a bit of formatting to make it more readable. However, an age-old history of changes or an individual’s perspective on the requirements is not needed. Stick to what is absolutely necessary for the successful completion of a task and elaborate on that. Not more, nor less. Keep the Backlog and Requirements Healthy and Updated Every project has a backlog—a list of ideas, implementation tickets, bugs, and enhancements to be addressed. Every project that does not keep its backlog well-maintained ends up in a pickle sooner rather than later. Some of our pro-tips on maintaining a healthy backlog are: Gradually add the requirements to the backlog: If not for anything else, you’ll have a point of reference at all times, but moving them there immediately may cause certain issues as they may change before you are ready for implementation. Keep all the work of the development team in a single backlog: Spreading yourself thin across several systems that track bugs, technical debt, UX enhancements, and requirements is a big no-no. Set up a regular backlog grooming procedure: You’ll get a base plan of future activities as a result. We’d like to point out that said plan needs to remain flexible to make changes based on feedback and/or tickets from marketing, sales, and customer support. Have a Product Roadmap in Jira Jira is definitely not the go-to tool for designing a product roadmap, yet having one in your instance is a major boon, because it makes the entire scope of work visible and actionable. Additional benefits of having a roadmap in Jira include: It is easier to review the scope with your team at any time. Prioritizing new work is simpler when you can clearly see the workload. You can easily see dependencies when several teams are working on a project. Use Projects as Templates Setting up a new project can be tedious even if you’ve done it a million times before. This can be especially troublesome in companies that continuously deliver products with a similar approach to development such as mobile games. Luckily, there’s no need to do the same bit for yet another time with the right combination of tools and add-ons. A combination of DeepClone and Smart Checklist will help you clone projects, issues, stories, or workflow conditions and use them as project templates. Add Definition of Done as a Checklist to all of Your Jira Issues Definition of Done is a pre-release checklist of activities that determine whether a feature is “releasable.” In simpler words, it determines whether something is ready to be shipped to production. The best way of making this list accessible to everyone in the team is to put it inside the issues. You can use Smart Checklist to automate this process; however, there are certain rules of thumb you’ll need to follow to master the process of designing a good DoD checklist: Your objectives must be achievable. They must clearly define what you wish to deliver. It’s best if you keep the tasks measurable. This will make the process of estimating work much simpler. Use plain language so everyone who is involved can easily understand the Definition of Done. Make sure your criteria are testable so the QA team can make sure they are met. Sync With the Team After Completing a Sprint We have a nice habit of running Agile Retrospective meetings here at Railsware. These meetings, also known as Retros, are an excellent opportunity for the team to get recognition for a job well done. They can also help you come up with improvements for the next sprint. We found that the best way of running these meetings is to narrow the conversation to goods and improves. This way you will be able to discuss why the things that work are working for you. You’ll also be able to optimize the rest. Conclusion If there’s a product where there’s something for everyone—within the context of a development team—it’s probably Jira. The level of customization, adaptability, and quality of life features is an excellent choice for those teams that are willing to invest in developing a scalable and reliable process. If there’s anything missing from the app—you can easily find it on the Atlassian Marketplace. More
DevOps vs Agile: Which Approach Will Win the Battle for Efficiency?

DevOps vs Agile: Which Approach Will Win the Battle for Efficiency?

By Riha Mervana
As software development continues to evolve, there are two approaches that have gained a lot of attention in recent years - Agile and DevOps. Agile has been around since the early 2000s and focuses on delivering software frequently through iterative and incremental development. DevOps, on the other hand, is a newer approach that focuses on speeding up the software delivery process through collaboration, automation, and continuous delivery. While both Agile and DevOps aim to improve efficiency and collaboration within the development team, there are some key differences between the two approaches. Agile is focused on the software development process, while DevOps is focused on deployment, integration, and delivery. Agile uses a methodology of sprints, daily stand-ups, and retrospectives to deliver working software frequently. DevOps, on the other hand, uses continuous integration and continuous deployment to speed up the delivery process. Agile Agile is a software development methodology that focuses on delivering value to customers through iterative and incremental development. It values collaboration, flexibility, and customer satisfaction. Agile teams work in short sprints, usually lasting 1-4 weeks, and aim to deliver working software at the end of each sprint. Agile development involves continuous feedback from the customer and the team, and the ability to adapt to changing requirements. Agile practices include daily stand-up meetings, sprint planning, backlog grooming, and retrospective meetings. The Agile Manifesto defines four core values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. DevOps DevOps is a culture that emphasizes collaboration, communication, and integration between development and operations teams. The goal of DevOps is to improve the quality and speed of software delivery, by automating processes and reducing the time it takes to go from development to production. DevOps involves a combination of practices, such as continuous integration, continuous delivery, and continuous deployment. DevOps teams work in a continuous cycle of development, testing, deployment, and monitoring. This allows for rapid feedback and the ability to quickly fix issues. DevOps teams also value the use of automation tools, such as configuration management, orchestration, and monitoring tools. DevOps vs Agile Agile and DevOps are complementary approaches that share many of the same values and principles. Both aim to deliver high-quality software that meets the needs of the customer. However, there are some key differences between the two approaches. Agile is focused on the software development process, while DevOps is focused on the entire software lifecycle. Agile teams work in short sprints, while DevOps teams work in a continuous cycle. Agile teams rely on manual testing and deployment, while DevOps teams automate these processes. Agile teams prioritize flexibility and customer collaboration, while DevOps teams prioritize speed and efficiency. Agile DevOps Focus Software development process Deployment, integration and delivery process Goals Delivering working software frequently Speeding up software delivery and feedback Methodology Iterative and incremental Continuous delivery and deployment Process Sprint planning, daily stand-ups, retrospectives Continuous Integration and Continuous Deployment Team Self-organizing cross-functional teams Collaborative and integrated teams Communication Face-to-face communication, regular meetings Strong collaboration, communication and feedback loop Feedback Regular customer feedback and iterations Continuous feedback through automated testing and monitoring Culture Empowered and autonomous teams Collaborative, feedback-oriented culture Tools Agile project management tools, issue trackers Automated testing, monitoring, and deployment tools Which Approach Will Win the Battle for Efficiency? The answer to this question depends on the specific needs and goals of your organization. If your goal is to improve the speed and efficiency of your software delivery, then DevOps may be the better approach. DevOps allows for rapid feedback, quick issue resolution, and automation of manual processes. However, if your goal is to prioritize flexibility, collaboration, and customer satisfaction, then Agile may be the better approach. Agile allows for continuous feedback from the customer and the team, and the ability to adapt to changing requirements. Ultimately, the choice between DevOps and Agile depends on the specific needs and goals of your organization. It is possible to combine elements of both approaches to create a customized approach that works best for your organization. Conclusion DevOps and Agile are two popular approaches in software development that aim to improve efficiency and productivity. Both approaches have their own principles, practices, and benefits. The choice between DevOps and Agile depends on the specific needs and goals of your organization. It is possible to combine elements of both approaches to create a customized approach that works best for your organization. More
What Are You Doing All Day, ChatGPT — As a Scrum Master?
What Are You Doing All Day, ChatGPT — As a Scrum Master?
By Stefan Wolpers CORE
Understanding Technical Debt for Software Teams
Understanding Technical Debt for Software Teams
By Rajiv Srivastava
MVP Launched. Now What?
MVP Launched. Now What?
By Leonie Lacey
Tracking Software Architecture Decisions
Tracking Software Architecture Decisions

Maybe this sounds familiar to you: joining a new software engineering company or moving from your current team to a different team and being asked to keep evolving an existing product. You realized that this solution is using an uncommon architectural pattern in your organization. Let’s say it is applying event sourcing for persisting the state of the domain aggregates. If you like event sourcing; but do not like it for the specific nature of the product, most likely, it wouldn’t have been your first choice. As a software architect, you start to find the rationale behind that solution, find documentation with no success, and ask the software engineers that do not have the answer you were looking for. This situation might have a relevant negative impact. Software architectural decisions are key and drive the overall design of the solution, impacting maintainability, performance, security, and many other “-alities.” There is no perfect software architecture decision designing architectures is all about trade-offs, understanding their implications, sharing their impacts with the stakeholders, and having mitigations to live with them. Therefore, having a well-established process for tracking those kinds of decisions is key for the success and proper evolution of a complex software product, even more, if that product is created in a highly regulated environment. However, today’s software is designed and developed following agile practices, and frameworks, like SAFe, try to scale for large solutions and large organizations. It is key to maintain a good balance between the decision-making process and agility, ensuring the former does not become an impediment to the latter. Architecture Decision Records (ADRs) My organization uses Architecture Decision Records (ADRs) to register and track architectural decisions. ADRs is a well-known tool with many different writing styles and templates like MADR. Now the question is how to ensure the ADRs are in place and with the right level of governance. As we will see below, ARDs are written in markdown and managed in a git repository, where everybody can contribute, and a consensus shall be reached to accept them and move forward with the architecture decision. For that, we have created the following process: First Swimlane In this process, the first swimlane includes team interactions that triggers architecture concerns, requiring a supportive architecture decision. Those concerns will come mainly from: Product definition and refinement: At any level (e.g., epic, capability, feature, stories), architecture concerns are identified. Those concerns shall be captured by the corresponding software architect. Feedback from agile teams: Architecture decision-sharing sessions and inspect and adapt sessions (e.g., system demos, iteration reviews, and retrospectives) are moments where architecture concerns can be identified. It is key to understand if agile teams are facing problems with the architecture decisions made so far; if the teams do not believe in the architecture, it will not be materialized. Second Swimlane The second swimlane involves mainly the architecture team and optionally technical leads from agile teams. This team will meet regularly in an architecture sync meeting where the following steps will be taken: Step 1 Architecture backlog management: Concerns are registered in the architecture backlog as enablers, prioritized, assigned. The first task associated with enablers is creating the Architecture Decision Record. Step 2 Gather inputs and perform the analysis: The architect assigned to work on the ADR will gather additional inputs from the stakeholders, colleagues, and agile team members, working on spikes with the team to go deeper into the analysis when needed. During this state, the architect will collaborate closely with the agile teams to perform the required analysis and alternatives evaluation of several backlog enablers and spikes that might be needed. Step 3 Work on the ADR: The outcome of the previous state is used to write the ADR, condensing the decisions to be taken, the context around the decision, alternatives assessed, final decisions, and consequences, both positive and tradeoffs. The ADR is created in the source control system. In our case, using GitHub because it has a main branch for accepted ADRs and a feature branch for the ongoing ADR. Step 4 Publish ADR: Once the ADR is ready for decision, a pull request is created, assigning a reviewer all the relevant stakeholders. Revision is not limited to architects but is open to a wider audience, like software engineers from agile teams, product owners, product managers, etc. Third Swimlane The third swimlane goal is agreeing on the decision under discussion. In this context, the ADR is reviewed by the architecture team during their regular meetings (e.g., architecture alignment/architecture board). Ideally, the solution shall be reached by consensus, but if an agreement isn't reached in the expected timelines, the designated software architect (depending on the decision level, it can be an enterprise architect, solution architect, or system architect) will make the final decision. Step 5 Review ADR on Architecture alignment: The ADR owner provides a brief presentation of the ADR to their mates that will provide feedback until the next alignment. Step 6 Collect and review comments: ADR reviewers add comments to the pull request, providing feedback to the ADR owner that replies to the comments and applies the corresponding adjustments. This approach ensures all the concerns during the ADR definition are tracked and available for review at any time in the future by simply accessing the ADR’s pull request. Step 7 The designated Software Architect makes the final decision: This state is only needed if, for any reason, there is no agreement between architects and engineers. At some point in time, there should be accountability in the decision, and this accountability resides in the corresponding Software Architect. Ideally, this state will not be needed, but it is also true that a decision cannot be delayed forever. Step 8 Involve stakehoders: It will be bad news if you reach this state, which is there as a safeguard in case the decision taken by the architect is clearly wrong. Stakeholders are involved in the decision process to reevaluate the ADR and reach final agreement. Step 9 Sign ADR: Once the ADR is accepted by the majority of reviewers, it is merged to main. From this point, the ADR becomes official, and the corresponding decision shall be realized by the engineering teams, leveraging analysis and spikes performed in step 2. ADRs are now immutable. Step 10 Superseded former decision: If the new decision replaces a previously accepted ADR, it can be modified to change its status to “Superseded,” indicating by which ADR it is replaced. Conclusion This process might look a bit cumbersome, but it should not take more than a few days to decide once the analysis phase (step 2) is completed. The pros of such a process outweigh the cons by having a clear architecture decision history, easy to track from well know tools (e.g., GitHub, GitLab), and providing the highest value for a long-lasting solution. Also, it is important to note that this is a collaborative process that should help balance intentional architecture with an emergent design by the involvement of agile team members in the architecture concerns identification, decision analysis phase, and feedback sharing. I hope this can help you improve how architecture decisions are made and evolve. I am happy to hear from you in the comments!

By David Cano
The Three Daily Scrum Questions Won’t Die
The Three Daily Scrum Questions Won’t Die

The Daily Scrum serves a single purpose: inspecting the progress toward the Sprint Goal by reflecting on yesterday’s learning. Then, if the need should arise, the Developers adapt their plan to accomplish the Sprint Goal. While the theory may be generally accepted, applying the idea to the practice is more challenging. One of the recurring issues is the continued popularity of the “three Daily Scrum questions” from the Scrum Guide 2017. Let’s reflect on why answering these obsolete Daily Scrum questions negatively influences the Scrum team. The Purpose of the Daily Scrum The purpose of the Daily Scrum is clearly described in the Scrum Guide — no guessing is necessary: The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. Source: Scrum Guide 2020. Therefore, the Daily Scrum is an important event for inspection and adaption, run by the Developers, and guiding them for the next 24 hours on their path to achieving the Sprint Goal. The Daily Scrum is also the shortest planning horizon in Scrum and thus highly effective in guiding the Scrum team’s efforts: focus on the outcome. The Problem With the 3 Daily Scrum Questions However, this noble idea is tainted by a widespread habit: centering the Daily Scrum around answering three questions: What did I do yesterday? What will I do today? Are there any impediments?. Initially, these three Daily Scrum questions were added to the Scrum Guide 2017 as an example of how the Scrum team members may inspect the progress toward the Sprint Goal. However, these three questions quickly became synonymous with the Daily Scrum. So now, it was all about answering these three questions, turning the Daily Scrum into a sort of status report meeting, with Developers waiting in line to “answer these three questions” to the Scrum Master, the Product Owner, or maybe even a stakeholder. Unfortunately, the “three Daily Scrum questions” appeal to many practitioners: they are simple, efficient, and create a comforting routine. However, as a Scrum team, we care less about detailing our previous work and justifying why we deserve a pay-cheque at the end of the month. Instead, we want to understand whether we will meet the Sprint Goal. If the Scrum team’s progress is doubtful, given recent developments and learning, we want to take action to get back on track. Any form of a status report is a mere distraction and wasteful in that respect. Conclusion Scrum as a practice is outcome-focused; it is not about maximizing the number of tickets accomplished during the Sprint. Instead, as a team, we are interested in achieving the Sprint Goal. There are endless ways to run your Daily Scrum without falling into this 3-question routine. For example, walk the board and figure out what needs to be done to move the tickets closest to “done” over the finishing line. Please do yourself a favor and avoid turning your Daily Scrum into a boring reporting session. How are you running your Daily Scrums? Please share your tips & tricks with us in the comments.

By Stefan Wolpers CORE
Linking User Stories to a Data Model: A Tutorial for Agile Development With Jira and ERBuilder
Linking User Stories to a Data Model: A Tutorial for Agile Development With Jira and ERBuilder

User stories are an effective tool for capturing requirements and defining features in a way that is easy to understand, test, and verify. They are written in natural language, without any technical jargon, and are typically structured in a format that describes the user's identity, what they want to achieve, and why. For example, a user story might be something like, "As a customer, I want to be able to pay for my order online so that I can complete my purchase more quickly and easily." User stories are typically captured in a tool like Jira, which is a popular project management tool used by many Agile development teams. Jira allows teams to create and track user stories, assign them to team members, set priorities, and track progress. However, user stories are often just the starting point for software development. To turn a user story into a fully functional feature, you need to link it to the database objects in your data model. A data model is a graphical representation of the entities, attributes, and relationships that make up a system or application. It defines how data is stored, organized, and accessed by the software. Linking user stories to data model entities helps ensure that the software meets the needs of the end users. Also, linking user stories to data model elements can help in impact analysis. This allows for easier identification of potential impacts of changes to one part of the system on other parts of the system that depend on that data. This can help make more informed decisions about how to implement changes and minimize the risk of unintended consequences. In the following tutorial, we'll walk you through the process of creating user stories on Jira, exporting them as a CSV file, importing them into ERBuilder (a data modeling tool and documentation tool we will use in this tutorial), and then linking those user stories with data model entities such as tables, columns, relationships, procedures, and other entities. Step 1: Create Salesforce User Stories in Jira To start creating user stories in Jira, go to the desired Jira project and click on the "Create" button to initiate a new issue. Select the "Story" issue type or the type that is appropriate for the project you are working on. Fill in the necessary information for the user story, such as the summary, description, and any relevant details. Step 2: Export the User Stories to a CSV File To proceed with exporting user stories to a CSV file, access Jira's built-in export feature. Click on the "Filter" option located at the top of the screen. Next, choose "Advanced Issue Search" and apply the appropriate filters by selecting "Story" as the type or by directly selecting the relevant issues. You can now choose which columns to include in your exported CSV file by using the "columns" button and then clicking on “Done.” Columns you must have in your CSV export are Issue ID, Issue Type, Summary, Created date, Project name, Priority, Status category, and Description. Once you've applied the filters, look for the "Export" option located in the upper right-hand corner of the screen, and select the CSV file format to export the data. Step 3: Import the CSV File Into ERBuilder After downloading and installing ERBuilder, create a new ER diagram project in ERBuilder. Give the diagram a meaningful name that reflects its purpose. Otherwise, you can reverse an existing database and get the ER diagram. The next step would be to import the exported user stories from Jira. To do this, you can follow these steps: Navigate to “project” within ERBuilder. Open Requirements / User stories. Click on the "Import" button, which is typically located on the bottom left side of the screen. Browse and select the exported CSV file that contains the Jira user stories you want to import. Click on the "Open" button to complete the process. Step 4: Link the User Stories to Data Model Entities Now you can link a user story to the corresponding entity or attribute in ERBuilder. For example, if you want to link a user story to a table, proceed as follow: Select the user story that you want to link to your table. Go to the "Related tables" tab within ERBuilder. Use the search box to find and select your table. Once the table is selected, click the forward arrow to link it to the selected user story. An alternative way to link user stories to data model entities in ERBuilder is by using the Treeview, Browser, or Diagram navigation options. To do this, you can use the Treeview, Browser, or Diagram navigation options to find and open the entity you want. Open the entity by double-clicking on it. Navigate to the "Requirements/User Stories" section. Select the user story you want to link from the list on the left side. Click on the forward arrow to link the user story to the object. The same process applies to other data-model entities such as columns, relationships, constraints, triggers, procedures, and requirements. Once you have linked your user stories with your data model entities, you will be able to generate comprehensive data model documentation that can be used by your team to gain a better understanding of the project's requirements and the corresponding entity elements.

By John Slaven
A Proposal for the Less Conventional
A Proposal for the Less Conventional

In the list of activities in the Scrum software development life cycle ranked by their popularity amongst developers, “attending meetings” is perhaps locked in a perpetual battle only with “writing documentation” for the position of last place. It’s quite understandable: meetings can easily become very boring — especially when a participant does not have anything to contribute to the meeting at hand — and are often perceived as having little value (if at all) compared to conducting actual code-writing in the software development project. However, these Scrum meetings can and do provide value to the project, even if the members of the team do not perceive it: Sprint refinements enable a product owner and the team to plan out development tasks in the weeks/months to come as well as identify whether any task might need further examination and/or design. Sprint plannings define what work the team should be set to accomplish in the given sprint period. Sprint demos provide visibility to other teams and/or project stakeholders into what a team is working on and has accomplished and permits questioning for clarity regarding the work (or even challenges to ensure that the produced work is robust and has fulfilled all objectives). Sprint retrospectives allow a team to identify factors in the previous sprint that were well-received, could be addressed for improvement or elimination, etc. This is, of course, merely reciting from the doctrine of Scrum. Whatever benefits these meetings may hope to provide will not appear if the participants of the Scrum meeting are not interested in “playing their part” in said meetings — execution, after all, eats strategy for breakfast. What can be done, then? One could: Dress up the Scrum meetings in cute metaphors — for example, using t-shirt sizes instead of point poker for story effort estimation during sprint refinement. This still leaves it clear that the meetings are exactly what they are, i.e… overhead to a project that the team members have to trudge through. Simply press the benefits of Scrum and appeal to the team members’ professionalism so that they step up and provide the necessary meeting input. Even with the most skilled motivator conducting this speech, it runs the risk of sounding browbeating or haranguing and might conduct the opposite effect of bringing morale down. Instead… As much as these attempts may be well-intentioned, they usually do not succeed in raising enthusiasm or buy-in for the meetings. In my opinion, this is due to the thought process behind the endeavors confining itself to the traditional definition of the meetings: they are still held as bog-standard meetings wherein the description for how the ceremony should occur is followed nearly point-by-point. Instead, it’s possible to make these meetings less “painful” for those involved in other ways by employing some outside-of-the-box thinking. For this, I would like to provide two examples from my own experience working at LucaNet of meeting formats that improved engagement while still providing the same desired output. Expand the Scope: Sprint Demonstrations At first glance, the objective of the sprint demonstration seems very straightforward: having the project’s teams provide a demonstration of whatever they have accomplished in the past sprint. This usually comes with the added stipulation that these demonstrations be related to the teams’ sprint goals; what if there is no such restraint for the teams? The sprint demonstration could be transformed into a type of internal meet-up, where not only do teams provide an exhibition of what they have worked on for their projects but also present topics that they feel might benefit the other teams as well. For example, a team whose members are inclined to experiment and conduct exploration of performance-related subjects might present their findings of programming language patterns to embrace (or avoid! ), whereas another team could show off a new technology that they have investigated. Aside from allowing developers to present items that genuinely interest them, permitting such presentations has the added benefit of allowing teams that might otherwise be unengaged in such meetings to participate as well, e.g. a tech-support team that would not normally have work that is related to the development sprint. Given that these meetings would undoubtedly take longer to conduct than ones that only presented sprint-related topics, it would be beneficial to adopt other aspects of tech demonstration meet-ups such as providing food and drink for the attendees, allowing voting (and small prizes) for the “best” presentation, and so on. Remove the Formality: Sprint Retrospectives It’s possible to take a step even further than before: instead of modifying the meeting’s “permitted” activities, why hold a “business meeting?” The objective of the sprint retrospective is to obtain feedback from a team’s members about how the previous sprint went, what they would retain/improve/eliminate, etc. This requires communication from the team members about their experiences, and such communication about past experiences and the opinions thereof is, in effect, a group conversation. There are other settings in which this kind of group conversation can be cultivated; one such example would be a team meal. As in, the team assembles for a meal — breakfast, lunch, dinner, whichever — and talks about their experiences during the previous sprint while they eat and converse about whatever other topics they might have in mind. Whether this food is provided by the company or by the participants of the meeting is up to the organizer, although having the participants supply the food (aside from being cheaper for the company!) adds the intrigue of a pot-luck wherein the participants can introduce their colleagues to foods that those colleagues might not otherwise be acquainted with, something especially poignant when working on a team with members from different cities or countries. However, the main benefit of this approach is the atmosphere that it helps to create. At its core, the sprint retrospective is an exercise in catharsis: the participants “unload” the feelings — both positive and negative — that they have accumulated during the sprint about how the sprint played out. When converting this meeting into a shared meal, the setting switches from the formal to the informal, and this relaxation of the ambiance can help draw out these feelings from the participants better than in the traditional format of the meeting, meaning more effective feedback and thus more effective input for how to improve further sprints in the future. Parting Words A qualifier that needs to be made here is that the practices described above occurred during the pre-COVID era — that is to say, before the widespread adoption of remote work. Some of the practices would undoubtedly need to be adapted for companies whose teams comprise members that never (or almost never) see each other in the physical world — for example, holding team breakfasts via a video call and from the confines of each team member’s own dining room or kitchen — and there is likewise the possibility that the productive effects of the approaches might be different for remote teams compared to in-person teams. Nonetheless, the base principle stands that it may be worthwhile to challenge the conventions of traditional meeting formats to discover whether any modifications to a group’s meetings can result in more productive and engaged teams. Reinventing the wheel does not need to be the be-all and end-all; it may very well be that what is already prescribed is the best solution for the team at hand. However, even such cases would stand to benefit from this exercise, as the end result would still be an introspection as to what truly serves the team well for its development process.

By Severn Everett
Sprint Velocity: The Ultimate Guide
Sprint Velocity: The Ultimate Guide

The software development process is complex. It involves various tasks that need to be distributed among teams and completed within a designated time frame. Managers need to be on top of the software development process and establish a workflow that can be traced, as mismanagement of even a minuscule size can lead teams to compromise on deadlines. This is where a metric like Sprint Velocity can help set achievable targets and gain visibility into the process. What Is Sprint Velocity? In the agile development framework, teams divide the available time into smaller durations or sprints, which can be certain days or weeks. The number of completed tasks at the end of each sprint is the velocity of that particular sprint, and the average velocity value across these sprints is the sprint velocity of the entire development process. Calculating sprint velocity is crucial in the development process as it determines the success rate in achieving deadlines. Apart from helping determine achievable deadlines, the sprint velocity metric also finds other applications in the agile development process and in the developer's well-being. How is Velocity Helpful for Scrum Teams? Regularly tracking sprint velocity can help software teams gain visibility into the project's progress and blockers hindering it. Not achieving the target sprint velocity can signal issues managers can look into and analyze. This enables them to understand the blockers in the development process and identify gaps — both internal and external. Here are other insights that can be obtained by calculating sprint velocity: Understand the technical difficulties in the project Optimize resource allocation between sprints Uncover blockers in different stages of the development process, be it writing codes, testing, or feedback and rework Discover if there are any discrepancies in the objectives provided by stakeholders Find out if the requirements are changed frequently Though the benefits of constantly calculating sprint velocity are plenty, there is no one way to do it. Organizations have multiple concepts to calculate sprint velocity in their agile planning process. How Do We Measure and Visualize Sprint Velocity? Every team, every project, and every client is unique. Hence calculating velocity across these verticals can be challenging. Over the years, organizations have come up with different variables and constants that can help them calculate and analyze the sprint velocity. The most common among them are: User story Capacity Definition of Done Velocity graph Burndown chart User Story A user story is the quantifiable translation of the requirements needed to complete a particular feature, module, or product based on the benefit from an end-user perspective. The user story is assigned points based on the complexity and effort needed from a minor story or bug fix, earning 1 point and a significant development or edits ranging between 5 to 8 points. Again, this varies across sprints, teams, and departments. Capacity Planning capacity for the team helps arrive at a realistic valuable available to complete the user stories. Capacity planning helps estimate the available bandwidth to develop, test, and edit user stories. This metric is arrived at by calculating individual availability and mapping it to the list of user stories, thus giving the aggregate of the time the team has to complete the task. Assuming a developer ideally has 6 hours of productivity bandwidth after meetings, breaks, and other routine activities, and a team has about eight developers working five days a week for three weeks, the capacity is 720 hours. Definition of Done (DoD) Defining the Definition of Done is an agreed-upon set of conditions or acceptance criteria that a process must meet for it to be complete in the perspective of the end user. It can contain various parameters such as testing, review, documentation, and so on, but should meet the completed criteria set by the end user. Velocity Graph The velocity graph comes in handy while calculating the sprint velocity as it highlights the amount of work done and the amount of work remaining in the user story or task. It provides insights into the average amount of work to be completed to achieve the desired results in the sprint. The story point is plotted along the y-axis, and the completed sprints are on the x-axis, and both come together to provide an understanding of the team's performance and set up future targets. Burndown Chart While almost similar to the velocity graph, the burndown chart gives insights into the team's progress in completing the committed task across all user stories within a single sprint. The slope of the burndown chart helps predict if the story will be completed early, on time, or late. Sprint Velocity Is Not the Only Metric You Need As mentioned earlier, the spring velocity formula can differ across teams, processes, projects, and clients. Managers should not target a higher sprint velocity and align goals to increase the number. In fact, sprint velocity is: 1) Variable 2) Descriptive 3) Arbitrary Increasing the velocity alone can be complex and counterproductive, especially without any data or tools to back it up. Managers should also leverage other assessment factors like better code reviews, quality assessment, and better planning throughout the development process by taking a data-driven stand rather than a completion-oriented one. Managers should have access to other software development metrics like code churn, maker time, and even async stand-ups to identify blockers effectively and leverage the gathered insights from these metrics to improve sprint velocity. To do this, they need an engineering analytics platform that encompasses the critical tools and analytics to optimize the software development process.

By Avya Chaudhary
The Context: Introduction
The Context: Introduction

Every software project has its own aura. That aura existed before the project was even started. It gave birth to the project and will be alive when the project will be decommissioned and/or replaced with some other project. This aura is The Full Context. The Full Context consists of all information directly or indirectly related to the project. It's the single source of truth for every single decision related to the project, from the decision to start it to the name of every variable in the code. The Full Context is enormously big and contains a lot of business, economic, and political information, such as company finances, the influence of persons or groups on particular decisions, or even the state of the mood of the developer that affected a particular decision. Dealing with such huge amounts of information is possible only by layering it into a hierarchy of abstractions. Each layer of the hierarchy consists of elements — each element can be considered a word, and the whole set of elements at the same level of abstraction: the language. This language is then used by the next layer of abstraction to express words used by the layer above, and so on and so forth. In most cases, there is no single "root" abstraction and no single hierarchy of abstractions. Instead, the context information is structured as a bunch of independent hierarchies. It should be noted that strict layering of abstractions is essential to keep context comprehensible. Abstractions leaking to upper levels may result in uncontrolled growth of complexity and make context an incomprehensible mess. The Context The hierarchical context structure enables us to extract only the technical part of The Full Context, i.e., the part directly related to the project. Let's call this part The Limited Context, or simply The Context. This part of the full context is the only one usually necessary for development. To abstract out non-technical aspects, it is convenient to consider The Context as the single source of truth of all made project-related technical decisions. This abstraction removes "why" these decisions were made by removing all non-technical factors. This is a deliberate decision, necessary to limit complexity by keeping only parts essential for software development. The Context is constantly updated and extended by new technical decisions we make every day. If some decision is not yet part of The Context, the decision is somehow made (usually using procedures specific to a particular team/company/product/etc.) and put into context. These decisions, therefore, look like a "decision map," which maps each "issue" to a particular "decision" and invokes a predefined procedure if an element is missing. From general considerations, it makes sense to keep this "decision map" as small as possible because it directly contributes to the complexity of The Context. In other words, it is preferable to have a smaller set of more general/generic decisions that covers a wider range of similar situations. Inside The Context Let's take a closer look at The Context and check what else is there. Besides decision map, there are: the real business domain the business domain model real business processes the model of business processes The word business here is a placeholder because what is business is up to each particular project and The Full Context which gave it birth. In the blockchain industry, at the top of the abstraction hierarchy, there will be blockchain domain and blockchain processes. In e-Commerce, it will be e-Commerce business, and so on and so forth. Note that, when we start digging into abstractions, we'll find that the business at each level of abstraction is different. It should be obvious: We split one of the top-level elements into subparts ("words"), where each "word" is responsible only for part of the implementation. This part of the implementation is the business of this word. This process goes down and down through the layers of abstractions. At the bottom, there are purely technical details like calls to a standard library or even more low-level stuff. Actually, detailing can be continued in-depth as deep as necessary (perhaps infinitely) from task context switches, through specific CPU instructions and cache lanes, via signals and buses, down to logic elements and the physics inside the chip die and PCB. Usually, there is a reasonable logical limit below which more details do not add any value. Obviously, if you are building an operating system, then system calls are your top-level language while everything below system calls is part of The Context domain or processes (again, limited to some reasonable level). The business domain model and the model of business processes are our project code. We use programming languages to encode and represent parts of the business domain and processes. In other words, code is a formalized encoding of the business, its domain, and its processes. It means that code is at best as good as the domain and processes. If you have a fuzzy domain or bad/inefficient/inconvenient business processes, the code is at least as bad (usually worse). Also, a map is not territory, so both models are only approximations of the real business domain and processes. It should be noted that relationships between business parts and their models are bidirectional. More often than not, the business is ready to change processes to match one proposed by software. The level of flexibility heavily depends on several factors and may vary. Usually, there is a tradeoff between price/time and the precision of modeling your processes/domain. From "buy ready to use software/subscription to service AND adjust all your processes to proposed model" (and get software up and running almost instantly for a few hundred/thousand $$) to "software should exactly reproduce our processes even if they are stupid, and we hate them" (and spend years and millions of $$), and everything in between. But not only processes can change. The domain of the project also may change. Usually, this happens, when the project scope is reduced or extended. A decision to reduce or extend the scope might be a consequence of the technical assessment or analysis. Nevertheless, it often is more convenient to consider these relationships as unidirectional (even if they're clearly not) and assume that real domains and processes are the sources of truth. Note that various design documents, architecture designs, and other similar stuff are not part of The Context. They could exist and even be useful if they precisely correspond to code, but the code is the source of truth about the domain model and model of business processes. Once we start thinking about project code with The Context in mind, we quickly discover the relevant decisions stored in The Context control code properties: How detailed the modeling is, compared to reality How precise the modeling is How easily real context can be restored from the code (context readability) How long the project will be used How performant it should be Basically, everything about the project is determined by The Context. For example, if you're implementing a one-time migration tool to migrate a legacy system to a new platform, requirements to code quality, maintainability, test coverage, context readability, etc. will be significantly different from those for a backend planned to be used for at least five years. Moreover, those requirements should not necessarily be identical across the whole code base. For example, we might sacrifice some context readability in a performance-critical part of the code to achieve the necessary performance. As one can see, a context-based approach is very business-focused, as opposed to traditional approaches, which are primarily focused on software. Of course, the connection to the business always existed, but it was usually just an input for software development. Specifications and requirements were eventually replaced/complemented by user stories and epics when the industry adopted agile methods. This significantly improved the connection with the business, but the focus on the software was left intact. A context-based view shows that it's not just a connection, but a tight coupling, where the business is a primary driver. The Code The main consequence of understanding of true relationships between business and software is the realization that existing approaches to software development might not be completely up to the task. Even a quick looks show significant issues with the traditional approach based on the best practices. The first thing to note: The traditional approach tries to establish identical practices for all projects. As we know, every project is unique, and setting identical requirements does not seem like an adequate solution (this kind of resembles the famous average pilot story). Second, but no less important: A significant part of the traditional approach relies on code readability as a justification. Overall, code readability is often considered one of the most important properties of code. The problem is that nobody knows what "code readability" is. Of course, every seasoned developer knows that it exists, but there is no reasonable definition for it. Existing ones are either self-recursive (i.e., funny but useless) or rely on other undefined terms such as "intent." This lack of definition means that every assessment of code readability is subjective, and there is no way to validate any given best practice that claims that it "improves code readability." Even the term "code readability" is misleading. If the code compiles, it is readable, at least by the compiler. Most likely, with some effort, code is also readable by the human, too. So, "code readability" is not about reading the code at all. Without a clear understanding of what code readability is, the whole traditional approach starts looking like a cargo cult. We're blindly repeating the same practices with the hope of getting a good result, but we have no idea why particular practices work or don't work in each particular case. A context-based view clearly lacks the issues mentioned above. Code represents parts of the context, and The Context defines the requirements of easily real context can be restored from the code. There is much less room for ambiguity because each practice can be easily validated, whether it helps preserve a necessary part of context or not in every use case. All of the above suggests that we need to significantly change our coding practices. But a detailed look into new coding practices is a theme for another article.

By Sergiy Yevtushenko
A Handy Guide to Agile Testing: Life Cycle Stages, Best Practices, and Tools
A Handy Guide to Agile Testing: Life Cycle Stages, Best Practices, and Tools

Agile testing is a core element of the Agile software development approach that empowers businesses to work on multiple phases at once. It is an iterative process that goes alongside the development process. Developers, testers, and customers work collaboratively to ensure software quality. If you're wondering if Agile testing is the right approach for your software development, read this article. It has answers to all your questions, including lifecycle stages, best practices, and tools. What Is Agile Testing? Agile testing is a software testing practice that follows the principles of Agile software development. This methodology starts at the beginning of development with continuous integration between development and testing. Unlike the traditional approach, where testing is done post-development, the requirements are gathered flexibly at each stage. Agile testing welcomes continuous feedback that helps developers make changes and resolve performance issues quickly. Other benefits include: Catch bugs faster and save time and money: Agile methodology helps reduce the number of bugs and resolve them in minimal time, preventing time-consuming and expensive fixes. Lightweight testing documentation: As most of the bugs and requirements are solved during the development stage, testers can focus on the essence of the test instead of incidental details. This reduces the need for documentation. Improved collaboration: Testers and developers can collaborate closely and communicate instantly without relying on documentation. This way, it enhances team communication and gives faster test results. High product quality: Here, development and testing go hand-in-hand. This enables the testers to implement preventive and corrective measures to improve software quality. Agile Testing Life Cycle Process The Agile testing life cycle is completed in five different phases. Let's check them out. 1. Impact Assessment During this phase, inputs from stakeholders and users are gathered, which then assists the testers in setting the objectives for the next life cycle. Thus, it is also known as the feedback phase. 2. Agile Testing Planning This stage includes planning the schedule of the testing process and deliverables by stakeholders. 3. Release Readiness In this stage, it is reviewed whether the developed features are ready to go live or not. If not, what changes are required to go further? Which features/modules need to go back to the previous development phase, and so on. 4. Daily Scrums This includes a standup meeting to catch up on the testing status and set the goal for the day. 5. Test Agility Review This Agile testing life cycle phase includes weekly meetings with stakeholders to check the evaluation and progress against the goals. Agile Testing Best Practices Focus on What You Need to Achieve You need to focus on one feature at a time when it comes to testing. This is a simple practice where you can ask your team to prepare the test cases for a particular feature or functionality testing. However, you must also ensure that you check the test case and review it for correctness. This is one of the prime aspects of Agile testing execution on the features and functionalities of the software. Test Repeatedly In Agile testing, testing before and after coding is highly important in order to check all the units of software precisely. You can even test during refactoring. Repeating tests will ensure that the new codes are maintainable and adhere to the new standards. Test the apps multiple times whenever there is even a small code movement, code merge, or change. In-Person Communication With Developers Agile testing is an iterative process. Hence, communicate with the developers and customers at each stage to know more about the features, requirements, and expectations. The clarity will help eliminate errors and bugs in the software while ensuring customer satisfaction. Goal-Oriented Work Approach Before embarking on the testing process, Q.A. testers need to plan a goal and decide the area of focus. In addition, being a tester, you need to understand the code-calling requirements and test suite framing. So, by adopting a well-planned approach, testers will find it easy to collect the application's functionality. Know When to Use TDD In software development, TDD (test-driven development) practice focuses on creating test cases before developing the actual one. This approach works best in some cases. You need to know when to use it, though. TDD helps to write and correct the failed tests before writing new code. Therefore, it is important to know when to use TDD since it helps avoid duplication of code even though writing a small amount of code in order to pass the tests. Here, tests mean the requirement conditions which developers need to test in order to fulfill them. Agile Testing Tools JIRA JIRA is one of the most popular Agile testing tools due to its ease of configuration. It is used for bug tracking, issue tracking, and project management. The widely used Agile testing tool also includes quality assurance processes in every step of software development to meet the requirements. Moreover, it has the capability to add plug-ins such as X-Ray and Zephyr to improve performance. Here're some of the key features of JIRA: Bug and issue tracking Audit logs Support for Agile methodologies such as Kanban, Scrum, etc. Custom workflows Agile reporting Allows over 3000+ app integrations. Selenium An Agile automation tool, Selenium allows the complete testing team to be involved in making automation test cases. It is suitable for web-based apps. Check out some of the key features of Selenium: Supports programming languages such as Java, Python, Ruby, Perl, PHP, and JavaScript. Automates browser-based apps. Serves as a framework for open-source test automation tools such as TestProject, Robot Framework, Katalon Studio, etc. Conclusion Agile testing has several benefits, such as improved collaboration, development flexibility, and time to market. In addition, it is a customer-centric approach that delivers quality products within the stipulated time. With the right partner, tools, and skills, you can get the most out of it. P.S. If you have any questions or want to share your thoughts on Agile testing, please share them in the comments.

By Hiren Dhaduk
Mind Map Reuse in Software Groups
Mind Map Reuse in Software Groups

Mind maps are used for exploring, clarifying, explaining, or planning. They are an effective way to gather and depict information. This could be information that we want to learn or knowledge that we want to share. We may want to focus on certain points, such as abstracting a number or details. Alternatively, we may want to plan our work ahead or explain how things work in detail. Brainstorming and finding connections between different ideas, solving problems, and creating new ideas, mind maps are a useful tool in our professional or personal lives. They go well beyond software development and they can be used in any human endeavor that requires critical thinking and decision making. A mind map could be anything that organizes our thoughts — drawings, diagrams, tables, keywords, pictures, graphs, Wikipages, and so on. It can be done with a pen and a paper, a marker and a board, or using mind mapping tools like Coggle, MindMeister, Ayoa, MindNote, XMind, etc. A number of software groups that I’ve been working with have been reusing mind maps to release features. Product owners, developers, and testers have found an effective way to avoid missing use cases and identifying edge cases. This helped toward requirements clarification and disambiguation, testability and completeness. Reusing mind maps has led to fruitful discussions, educated decisions, and information exchange between teams. Development Method Used There exist different development methods, like waterfall, agile, lean, extreme programming, prototyping, rapid application development, and others. There are also different flavors for different methods, whilst hybrid combinations could also exist. We will not focus on which method, flavor, or combination is better, but to avoid confusion, we must clarify that this article assumes an agile-like whole-team approach. Development teams contain (at least) developers and testers, and the team’s work is divided into missions. Each mission contains features to be released. For each mission, a product owner is assigned that focuses on business decisions for customers. Mind Maps for Different Roles in a Software Group Product Owner The product owner helps customers define functional and non-functional requirements. After all, this role tries to make the most out of development teams in each mission by fulfilling all requirements. This implies that all team members are pursuing a common goal, establishing priorities so that they work on the highest-valued functionality. Decisions are also made that lead to a good return on investment per mission. What is the value delivered per feature? Which feature is more important for any given set of features? Which feature should be developed first, which second and so on. What did the customer request? A mind map from a product owner could be per feature, or it could involve multiple features or the entire mission. This depends on the feature size and on the scope of the mind map. Size To analyze and explain large features that contain a lot of functionality, it will require more space on a board. When many large features are put in the same mind map, things may get difficult to understand. When a mind map contains tons of information, it is easy to miss details, and people usually get discouraged using it. However, when the scope of a mind map is to depict the functionality delivered during an entire mission, if large features are involved, then careful decisions will need to be made on what to abstract. Scope A mind map depicting interdependencies at a business level between different features will probably include only the interdependent features. A mind map focusing on a feature and its sub-features will probably abstract all other features. A mind map focusing on the security aspects of the delivered features will probably depict only the features involved in the security use cases. This is the context that needs to be clarified as far as a product owner is concerned. Developer Developers need clarity and completeness about what should be implemented. They decide how to write the implementation code and their tests. Based on mind maps from the product owner, they can create their own mind maps. It’s up to the developer what information should be depicted (the scope of the mind map). Is it used to clarify code interdependencies? Is it used to explain how things work? Is it used to depict what has been unit tested and what not? Is it used to request clarifications from product owners? Is it used to depict specific areas in the code that require attention from testers? Entity-Relationship Mind Maps Entities and their relationships are a basic way of analyzing software systems. Entities could be specific to the domain in which we are working, such as invoices for accounting systems, items in inventory systems, nodes in network management systems, or friends in social networks. Exploring entities and their relationships in a mind map has helped development and product teams achieve alignment on what should be developed. It has also helped testers identify edge cases and brainstorm with developers about performance bottlenecks. State-Transition Mind Maps Identifying events that trigger transitions between states is another way of analyzing software systems. For example, a log-in event may have triggered the transition from a logged-out state into an authorization state and then a logged-in state. States can be directly controlled by the UI and easy to identify like logged-in/logged-out. They can also be subtle, triggered by the passage of time (e.g., timers in our software system have expired) and are uncontrollable by the UI, like authorization. Mind maps depicting states and their transitions can be helpful in implementing and debugging. They can also help to identify edge cases and reproduce sporadic bugs. Tester This role tries to make sure that bugs are found and fixed before releasing features to the customers. After the release, testers try to verify that the evolution of features follows certain quality criteria. Testers create and execute (UI or API) tests from requirements. Mind maps from product owners as well as from the developers could be very beneficial. A product owner will include functionality that needs to be released. This is excellent for test-case design in black-box testing. Some development teams created mind maps to depict what has been tested at a unit level. This indicated to the testers what has been tested and what not. Testers may augment development mind maps to make sense of what needs to be tested. Here lies grey-box testing information. There were cases when developers shared mind maps depicting areas in the UI that needed attention from testers. This was another major source of grey-box testing information. Based on this kind of feedback from developers, testers could focus their testing efforts. Ecosystem Mind Maps An ecosystem includes the environment in which our software lives, all the interfaces into our software, and all the external dependencies. A mind map of the entire ecosystem could give a clear picture for investigating connections, dependencies, and risks associated with the parts of our system that are outside our software’s control. One team used ecosystem mind maps that depicted how their software connected to the outside world. The focus was on the interfaces, users, and connections to integrated systems. Another team used a deployment-based ecosystem mind map. It was focused on where the components that make up their system, such as databases, configuration files, and executables, live in a production deployment. Ecosystem mind maps helped testers to devise their own positive and negative testing mind maps. They also helped product owners to get a bigger picture of their software and consider use cases that would have been missed on requirements. Developers found edge cases that needed special attention on their code. Wrapping Up Mind maps are reusable, tailorable, and can be mixed and matched according to our needs. They can be an effective tool for exchanging information and boosting confidence between teams to release features. After all, it’s all about aligning with the common goal of making customers happy.

By Stelios Manioudakis
When Scrum Feels Like Dressing for Dinner
When Scrum Feels Like Dressing for Dinner

In a recent article titled Why Do Many Developers Consider Scrum to Be an Evil Scam, Scrum consultant Willem-Jan Ageling bemoaned the clear impression that people outside his professional circle didn’t share the same devotion to the framework, "I am a Scrum enthusiast. When I'm in my Agile bubble, I have the pleasure of having great conversations. We may have different opinions about approaches, but in the end, we mostly agree on the merits of Agile and Scrum. But when I leave my bubble, I often receive backlash. The worst thing I have been called is a snake oil salesman, selling an evil scam". I won’t unpick his arguments in detail. I don’t think Scrum is an evil scam and I don’t think Mr Ageling is a snake oil salesman. Yet I have seen Scrum being misapplied too often to ever become an enthusiast again. Here are my very personal reasons, based on first-hand evidence. It’s biased, but then I don’t pretend to speak for ‘many’ developers, let alone all. The tech world has been infatuated with Scrum to the point of becoming blind to alternatives. It is adopted without question and considered appropriate, even essential, for every software project. Yet most tools and techniques are not a good fit for every creative process. Each should be evaluated for its usefulness depending on the circumstance. Scrum is usually imposed by the organization company-wide. When not at liberty to ignore it, people go through the motions. Ceremonies feel like dressing up for dinner. Nobody likes it or sees the point, but we do it as a matter of etiquette. Framework Infatuation It’s fine to be enthusiastic about a technique of framework, but when you refer to a circle of like-minded individuals as a bubble – twice in the same paragraph no less, it speaks of more than rational professional preference. It speaks of fandom. The risks of that are obvious. It keeps you from throwing out the old when something better comes along. We don’t do that with people we love, and we’re loath to do it with cherished ideas. When something is close to your heart, faith too often trumps truth. In rational matters, this pushes science into religious territory. Save your love for other people or a more worthy cause. You are a human being before you are a Java professional. It’s okay to be pragmatic, even mercurial about picking tools and techniques to further your career. You’re not swearing an act of allegiance to Java or Microsoft. If you fall in love with C#, James Gosling won’t mind. I have invested heavily in the Java and JVM ecosystem over the past fifteen years, but I’ll go with the flow if the world moves in a different direction. Once I did a lot of Google Web Toolkit. It’s obsolete tech now, and rightfully so. I had fun, made good money, and moved on. No harm done. Besides an inability to recognize better alternatives, tool infatuation leads to the anti-pattern of the Golden Hammer. You think it’s essential and indispensable because you like it too much and don’t care to know what else is around. Sure, we can’t know all. We must separate the essential from the optional, given our limited cerebral resources. We must pick our fruits from the tree of knowledge with care because they take time to pick and go bad quickly. At the Devoxx 2022 conference, a frankly intimidating chart was handed out that covered many of the hard skills in the Java ecosystem, categorized into essential, good to know and nice to know. A commendable effort, which didn’t even touch on soft skills and said nothing about the required depth of each domain. Many branches in the tree had bookshelves and conferences dedicated to them. Radical Distraction Elimination Thankfully not everything in the Java domain is indispensable for every project. De-facto standards like JUnit and SLF4J spring to mind (pun intended). It all depends. Sometimes you need to go deep on a technique you haven’t used before. You can become the number one Quarkus guru in your postal district for a year and then not touch the framework for the next five years. I believe the successful developer of the future is a radical distraction eliminator and productivity optimizer. She’s looking for the human advantage over AI and knows that it is no longer in solving math puzzles or the nitty-gritty of the arcane Unix command lines. Time will tell how we can beat the machine and be worth our paycheck, but time and effort spent on something that doesn’t provide a business advantage or makes you cleverer is always wasted. This brings me back to Scrum. Management frameworks should be treated no differently from hard skills and software libraries. If they don’t help the team here and now, in this project, they hinder. Mileage always varies, whether it’s with a set of generic best practices or someone’s personal ‘secret to my success’. I’m sure every aspiring horror writer would love to know the routine that kept Stephen King so prolific for fifty years, but even if he does have a method, it’s his method. Scrum is not the method. Scrum is not tailor-made. It implements a generic support function that is nevertheless prescriptive, inflexible, and usually imposed as a mandatory way of working on a team. A prescriptive framework is about rules, not recommendations. You cannot use your own judgment to bend or suspend the rulebook at will, like in air traffic control. This is good when lives are at stake. But mandatory rules must have a firm scientific basis to justify their generic usefulness. This basis is lacking in Scrum, and neither do we find it in very opinionated statements from the Agile Manifesto about team autonomy and the superiority of oral communication. All this wouldn’t matter if teams had the liberty to just ignore Scrum and settle on a mode that suited them best. We know that’s not the case, especially not in the enterprise world. Scrum is usually imposed from on high and facilitated by people whose livelihood depends on it. Great facilitators and coaches understand that Agile is about context-dependent principles, not rigid procedures. These people possess a treasure trove of experience and an extensive toolkit from which to suggest what is needed at the moment, whether it’s from a proprietary framework or not. I haven’t met many of them. Dressing for Dinner Like every other member of the British upper class, the aristocratic Crawley family in Downton Abbey would dress for dinner. Even on a drab Monday, with no guests and nothing to celebrate. It was time-consuming and uncomfortable, yet nobody questioned its usefulness. They knew there wasn’t any. Their elaborate dining etiquette came with the job. They went through the motions. Ingrained habits will do that. More than once I have felt like that in standups and retrospectives, even in very casual attire.

By Jasper Sprengers CORE
Agile Scrum and the New Way of Work in 2023
Agile Scrum and the New Way of Work in 2023

The success of a software development process depends majorly on delivering projects and meeting deadlines. Or so it was always believed. However, working in such am environment resulted in the loss of quality of work, excessive reworks, and increased pressure on the software developers. In an attempt to solve this issue and to set up a much better working methodology, the agile way of working took form. The Origin of Agile Twenty years ago, 17 people from around the world gathered at a ski resort in Utah and created what we know today as Agile Software Development Manifesto. The core value of this new alternative to the traditional project management process was to place people and values at the core and work together to achieve results. The Agile approach to software development focuses on completing the project with iterations and constantly focuses on improvement and collaboration. The founding group that called themselves the Agile Alliance went on to create four central values of the Agile Software Development Manifesto: Unlike the waterfall approach, Agile methodology divides work into actionable items, called sprints, enlist feedback and reprioritize work as per business needs and market changes. List of the Most Popular Agile Methodologies The Agile approach focuses on achieving the goal of breaking the project into iterative blocks of work that focuses on continuous delivery. Below are the four major methodologies that highlight the Agile way of working: 1. Scrum One of the most popular Agile methodologies, the Scrum way of working, aims at breaking the entire development cycle into smaller cycles called sprints, which have variable completion rates. These completion rates are determined by the sprint velocity, which is the average of time it takes to complete all the sprints involved in the development process. Key Focus The Scrum methodology focuses on continuous development with insights into productivity across the sprints and also the blockers in the development process. The Scrum process also fosters better collaboration between teammates and consists of a Scrum master who manages the stand-up meetings to understand the progress and issues in the development process. 2. Kanban This visual form of workflow management originated in the manufacturing sector and later found its application in the software development process. This methodology of the Agile development process utilizes visual cues to provide visibility and track progress across the various stages of the development process. Key Focus Like the predecessor, the Kanban methodology focuses on continuous delivery with insights into the upcoming tasks through the Kanban board, which consists of the process flows in column view to deliver the projects on time. Users can get real-time visibility into the development process at any given time, along with a view of the development workflow. 3. Extreme Programming (XP) Extreme Programming also emphasizes dividing the entire project into shorter development cycles and gathering customer feedback and requirements at the end of each iteration. This makes it easier to incorporate any changes or includes new requirements without any hassle. Key Focus This Agile methodology has a keen focus on constant communication and customer satisfaction. This is achieved through continuous testing after each iteration, thus ensuring customer demands are met and there are no changes at the end of the development cycle. 4. Crystal The Crystal methodology of Agile development methodologies comprises a family of functionalities that include Crystal Yellow, Crystal Clear, Crystal Red, Crystal Orange, and more. All of the above have a unique framework that is categorized by various factors, such as the criticality of the project, the size of the team, and the different priorities in the project. Key Focus Like all the Agile methodologies above, the Crystal approach focuses on the quick and continuous delivery of projects and customer satisfaction. According to the 16th Annual State of Agile Report, Scrum has been voted the most popular Agile way of working, with 66% of the 4,182 respondents identifying it as the methodology they follow. Benefits of Agile Scrum Software Development Cycle According to Project Management Institute, 71% of U.S. companies are using Agile methodologies to manage their software development cycle. So it is safe to say the agile way of working is the most common in software development. The benefits of the Agile way of working are vast, from faster time to market and better visibility to improved customer satisfaction. The Agile framework’s focus on collaboration and continuous improvement also makes it an efficient approach to modern software development. Here are other ways how it drives digital transformation with visibility into improvement through: Flexibility Breaking down the entire SDLC process into smaller cycles provides better control and flexibility as teams can observe one cycle, gather inferences and gain insights into making the iteration process more efficient. Adaptability The iterative framework enables teams to adapt to new requirements and processes better, owing to the observations from the gathered data. This also helps in better resource allocation and adaptability across the development cycle. Process Optimization The Agile way of working helps managers to optimize the process until the desired result is achieved at the desired time, cost, and quality. Optimization is possible due to the focus of the Agile process on continuous delivery and improvement. Risk Mitigation The insights generated after every iteration, equipped with traceability and collaboration of the teammates, help efficiently uncover the blocker in the development process. Managers can also track the pattern across the entire development cycle and zero in on issues and hindrances better. Agile and the New Work Normal Ever since the onset of the pandemic the world has witnessed massive shifts in the way of working. And though the world has returned to normal to an acceptable extent, the workforce that witnessed a paradigm shift in the way of working has fully adapted to the hybrid and remote way of working. This new normal has been a revolutionary change in the global workforce that is beneficial to both the organization and the employees. This is the future of work and it is defined by the streamlined focus on digitization, data, and people. The new work environment enables employees to preserve their focus time and maintain a better work-life balance, thus reducing the chances of employee burnout. Coming to software development, the remote and hybrid way of working has cut down the manual efforts in everyday mundane tasks and updates, thanks to automation tools and software that enable them to focus on the tasks and their well-being. In fact, Agile adoption went up by 33% in the mid of 2020, which is the initial phase of the shift to remote working. According to the 15th State of Agile Report, which was recorded in 2022, 89% of teams are geographically distributed, and working hybrid; this clearly establishes remote working to be the new normal. To help manage this new era of working, managers should adopt a data-rich platform that enables them to drive digital transformation in the software development process and generate data-enriched reports through high integrations. This empowers them to automate processes and focus on people. However, this scenario is only feasible for organizations that have added an analytics tool to their software arsenal. Final Words It is clear that the Agile Software Development Cycle is the future of work. Therefore, organizations should take the first stride to adopt and maximize the functionalities of this popular and efficient framework. To make the process successful, organizations should also utilize other software metrics like sprint velocity, code churn, and other that helps optimize the agile framework and achieve the desired results. However, individually measuring these metrics can be difficult and have limited value. An Engineering Analytics tool solves the issue by providing a platform that efficiently integrates with everyday software tools to gather data, analyze them and provide actionable insights without disturbing the focus time of the teammates.

By Avya Chaudhary

Top Agile Experts

expert thumbnail

Jasper Sprengers

senior developer,
Team Rockstars IT

I have been working in software since 1999, writing on whatever fascinates me about the craft, with a special interest on sensible agile practices, testing and documentation.
expert thumbnail

Alireza Chegini

DevOps Architect / Azure Specialist,
Smartwyre

Alireza is a software engineer with more than 20 years of experience in software development. He started his career as a software developer, and in recent years he transitioned into DevOps practices. Currently, he is helping companies and organizations move away from traditional development workflows and embrace a DevOps culture. Additionally, Alireza is coaching organizations as Azure Specialists in their migration journey to the public cloud.
expert thumbnail

Dr. Srijith Sreenivasan

Director,
Schneider Electric

‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎
expert thumbnail

Martin Fowler

I am an author, speaker, and loud-mouth on the design of enterprise software. I work for ThoughtWorks, a software delivery and consulting company. @martinfowler

The Latest Agile Topics

article thumbnail
Accelerating Enterprise Software Delivery Through Automated Release Processes in Scaled Agile Framework (SAFe)
By automating and incorporating quality gates and security scans in the CI/CD pipelines, businesses may improve the quality of their software products.
March 22, 2023
by Praveen Kumar Mannam
· 4,529 Views · 2 Likes
article thumbnail
5 Best Python Testing Frameworks
In this article, readers will find an honest comparison of the top 5 Python frameworks for test automation. Discover all their advantages and disadvantages.
March 21, 2023
by Arnab Roy
· 2,043 Views · 1 Like
article thumbnail
Tracking Software Architecture Decisions
Readers will learn a method for systematically tracking software architecture decisions through ADRs, introducing a lifecycle that will support this process.
March 20, 2023
by David Cano
· 1,986 Views · 1 Like
article thumbnail
The Stoic Scrum Master
Could it be that the first principles of “agile” were defined “Zeno of Citium in Athens in the early 3rd century BCE?”
March 16, 2023
by Stefan Wolpers CORE
· 1,486 Views · 1 Like
article thumbnail
How to Make Testing Progress Visible
Testing efforts can easily go under the radar or be hard to grasp. It's important to remember that software testing is not only about running tests.
March 16, 2023
by Federico Toledo
· 1,263 Views · 1 Like
article thumbnail
Tools to Track and Manage Technical Debt
It's hard to make the right decision. We will look at the tools to track small, medium, and large pieces of debt and the process to reduce technical debt.
March 15, 2023
by Alex Omeyer
· 10,067 Views · 3 Likes
article thumbnail
Developer Productivity: The Secret Sauce to Building Great Dev Teams
Developer productivity is the amount of quality and reliable software developed efficiently by an engineering team, and depends on code reviews, SDLC flow, team well-being and developer experience. Let's see how great dev teams are formed and why developer productivity matters.
March 15, 2023
by Avya Chaudhary
· 2,144 Views · 2 Likes
article thumbnail
Linking User Stories to a Data Model: A Tutorial for Agile Development With Jira and ERBuilder
In the following tutorial, we'll walk you through the process of creating user stories on Jira, exporting them as a CSV file, and importing them into ERBuilder.
March 14, 2023
by John Slaven
· 1,240 Views · 2 Likes
article thumbnail
5 Software Developer Competencies: How To Recognize a Good Programmer
It’s also only useful if it meets business requirements and is of adequate quality. So we need to assess the skills that enable a developer to meet these goals.
March 14, 2023
by Mohamed Aboelez
· 3,001 Views · 2 Likes
article thumbnail
What Is the Software Testing Life Cycle?
In the world of Agile software development, software testing isn’t a single stage carried out just before the release of your application.
March 13, 2023
by Anna Smith
· 1,651 Views · 1 Like
article thumbnail
DevOps vs Agile: Which Approach Will Win the Battle for Efficiency?
Confused about which approach is better for achieving maximum efficiency? Check out our comprehensive guide to DevOps vs Agile and make an informed decision!
March 12, 2023
by Riha Mervana
· 3,753 Views · 2 Likes
article thumbnail
MVP Launched. Now What?
How should you measure your MVP's success and what to do with the data? Here's what we can tell you after 15 years of refining our approach to product development and growth.
March 12, 2023
by Leonie Lacey
· 2,313 Views · 1 Like
article thumbnail
Understanding Technical Debt for Software Teams
What is technical debt? How do you fix it? Stay competitive in the market with the best practices and explore ways to remediate technical debt. Learn more.
March 10, 2023
by Rajiv Srivastava
· 2,641 Views · 1 Like
article thumbnail
10 Best Ways to Level Up as a Developer
Ensure you are follow the best practices as a programmer by taking advantage of this guide detailing the top ten ways to improve your development skills.
March 10, 2023
by Bhavesh Patel
· 3,767 Views · 2 Likes
article thumbnail
The Three Daily Scrum Questions Won’t Die
Learn how to overcome this legacy and move from a reporting session of the individual to real teamwork.
March 7, 2023
by Stefan Wolpers CORE
· 1,713 Views · 3 Likes
article thumbnail
How Does SAFe Differ From LeSS?
An overview of two Agile frameworks
March 4, 2023
by Dr. Thomas Baxter
· 3,255 Views · 2 Likes
article thumbnail
The Many Benefits of Collaborative Leadership in Modern Workplaces
Collaborative leadership comes naturally to a handful of expert project managers these days. Here's what you need to know to get started the right way.
March 1, 2023
by Fred Wilson
· 2,207 Views · 1 Like
article thumbnail
What Are You Doing All Day, ChatGPT — As a Scrum Master?
Read on and learn what ChatGPT considers to be a typical workload.
March 1, 2023
by Stefan Wolpers CORE
· 2,709 Views · 1 Like
article thumbnail
Observability-Driven Development vs Test-Driven Development
This article briefly explains what ODD and TDD means. What the similarities and differences between ODD and TDD are and best practices for implementation.
February 28, 2023
by Hiren Dhaduk
· 3,602 Views · 1 Like
article thumbnail
Application Development: Types, Stages, and Trends
If you want to start your career as a web developer, then this article will help you understand the types, stages, and trends.
February 27, 2023
by Saanvi Sen
· 2,896 Views · 3 Likes
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • ...
  • Next

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: