Learn How to Structure Your Site for Optimal User Experiences

When building a website, one of the first things to be considered is its structure. This is fundamental to the success of a site and, if planned properly, can avoid many issues further down the line. Website architecture design involves planning the layout and design of the website, identifying the pages to be included, determining how consumers will navigate the site, and planning how these pages will link together. Based on the learning from market research and competitor website performance, the marketing team—along with subject matter experts, such as website developers—is responsible for ensuring the optimal website architecture design.
One of the factors that the marketing team must consider when planning the website architecture is click-depth. Click-depth or crawl-depth refers to the minimum number of links a website visitor must click in order to get from the “root” web page to a particular desired web page. The root web page is the page that displays when only the domain is in the URL (no path information). Businesses must ensure that the click-depth is kept as low as possible, so that users and search engines can reach any point on the site within a minimum number of clicks.
The marketing team analyzes how each page will be linked internally and externally, creating categories and subcategories within the site. While creating the website, search-friendly URLs should be used to increase the relevance of the links and help the organic ranking for the website. As well, duplicate meta tags, meta descriptions, and titles should be avoided to prevent confusing web crawlers.
In short, the website design architecture should assure visitors they are on the right page; ensure visitors can easily find what they are looking for by providing a clear navigation path and search feature; properly link together and by ensuring the various pages; and ensure that the website is easy to navigate not only for customers, but also for web crawlers, so that they can be detected by search engines.
[Acknowledgement: This post has been burrowed from https://www.SMstudy.com with due permission. Original can be found at https://www.smstudy.com/article/learn-how-to-structure-your-site-for-optimal-user-experiences]

Common Scrum Pitfalls

Scrum is a highly viable software development methodology, and the teams implementing Scrum seldom experience failure. However, it would be wrong to assume that Scrum is a panacea for all sorts of problems and impediments surfacing during the development process. As a matter of fact, if the team implementing Scrum fails to deliver, Scrum is not to be blamed as a process by itself never goes wrong; instead, the shortcomings and flaws lie in the implementation of that methodology. To put this in other words, there are a number of pitfalls that a Scrum team can fall into as a result of which things can go haywire and the whole purpose of implementing Scrum can be defeated. Some of the common Scrum pitfalls are mentioned below:

  1. Excessive Up-front PlanningScrum teams should not indulge in up-front planning; rather, the team should begin coding and development straight away. There is no point in wasting time on deciding the Product Backlog much in advance as the feedback gathered during Sprint Reviews and Retrospectives is important in planning the subsequent sprints.
  1. Focus On Tools – Tools are not important; people and processes are. So, there is no need to worry about tools. ‘Finding the appropriate tool’ is just an obstacle to getting started, so the teams should start with the development right away.
  1. Problem-Solving in the Daily Scrum – Daily Scrum is neither for discussing problems nor for finding solutions to those problems. Daily Scrums should essentially be time boxed to 5 minutes and be limited to answering the three questions.
  1. Management or Stakeholders managing the team – Scrum requires teams to be self-organizing and self-managing; therefore, neither the management nor the stakeholders should try to manage the team or should assign them work. On the other hand, the team too should not wait for either the Project Manager or the Team Lead to delegate the tasks to the team members.
  1. Scrum Master As a Contributor – Scrum Master is a specialized role; a Scrum Master is supposed to be watcher and a facilitator, not a developer or a tester. So, he should not be assigned any other duty. Also, he should not direct the team in what to do and what not to do as this would distract him from monitoring whether or not the team adheres to the Scrum principles.
  1. Imposed Deadlines and Resources – Scrum teams know best what to complete in a particular Sprint, so neither the stakeholder nor the management should try imposing deadlines or prescribing resources as this would not only demotivate the team, but also reduce their productivity and the quality of the software produced.
  1. Distributed Team – Scrum prefers collocated teams as distribution of team members impedes direct and open communication which in turn reduces productivity and quality.
  1. Product Owner Doesn’t Show – Presence of the Product Owner in Daily Scrums and Retrospectives is essential as he is the bridge between the technical team and the stakeholders. Since feedback given during the Retrospectives is important in planning the succeeding sprints, the Product Owner’s presence is vital.
  1. Stretch Goals – Since Scrum follows the iterative and incremental model of development, the team pre-decides what to do in a Sprint. As such, neither the management nor the stakeholders should try to overload the team with more work as this will result in decreased efficiency and in increased resentment.
  1. Individual over Team – Scrum believes in the dictum that Scrum team swims or sinks together. So, individuals should not try to work beyond their prescribed roles. Overtime as well as individual heroics should be discouraged.
  1. Fixing problems over restarting the Sprint – Failure in immediately restarting the Sprint is one of the major pitfalls. This happens because the team makes itself busy in fixing problems surfaced in the previous as a result of which the project gets extended beyond the stipulated time.
  1. Product Owner Specifies Solutions – Problems are bound to surface during the development process; however, the team, not the Product Owner should come up with the viable solutions to such problems. This is because the team is well versed with the technical aspects of the software under development.
  1. Compromising On Quality – Delivering a high-quality, business valued, and potentially-ship-able product is the very foundation of Scrum; however, many teams tend to give up on quality due to limited resources or due to pressure to release features. This is one of the most common Scrum pitfalls.
  1. Ceasing to learn – Scrum believes in evolutionary development, and this requires constant learning on the part of the team members; however, the team members cease learning and acquiring knowledge about the processes and techniques. This is because they assume that they have come to know all that there is to be known about this methodology.
  1. Frequently reconstituting Scrum team – A scrum team should comprise of experts in order to make it a high-performing team that delivers quality products. Practically speaking, it is very tedious and difficult to form such a team. So, shifting members frequently not only brings down efficiency and productivity but also demotivates the team members. Plus, this is wastage of precious time.

The above discussed points are the common pitfalls that a Scrum team can fall into; however, there can be number of other pitfalls as well since Scrum is a highly flexible methodology and software development is quite a dynamic activity. Whatever may be the scenario, Scrum teams can avoid such pitfalls if they adhere to Scrum principles as closely as possible.

How is the process of Demostrate and Validate Sprint helpful in a Scrum Project?

At the end of every Sprint it is important to demonstrate and validate the sprint so that theScrum

Project runs on the desired line of product development. This process is an essential part of the

Review and Retrospect phase of the Scrum Methodology.

The key inputs of this process include

1. Scrum Core Team*

2. Sprint Deliverables*

3. Sprint Backlog*

4. Done Criteria*

5. User Story Acceptance Criteria*

6. Stakeholder(s)

7. Release Planning Schedule

8. Identified Risks

9. Dependencies

10. Scrum Guidance Body Recommendations

The (*) is for mandatory inputs.

The tools of the process are:

1. Sprint Review Meetings*

2. Earned Value Analysis

3. Scrum Guidance Body Expertise

The outputs of this process is helpful in ensuring that only the desired products make it to the final

accepted list and also prepared the Scrum Project for risks and its timely management. The outputs

are as follows:

1. Accepted Deliverables*

2. Rejected Deliverables

3. Updated Risks

4. Earned Value Analysis Results

5. Updated Release Planning Schedule

6. Updated Dependencies

Managing Changes through Prioritized Product Backlog Grooming

Managing Changes through Prioritized Product Backlog Grooming

A typical Prioritized Product Backlog will contain all User Stories, their time estimates which also includes any revised estimates, and the status of higher priority requirements. Any new or revised User Stories resulting from changes to business requirements, customer requests, external market conditions, and/or lessons learned from previous Sprints are also incorporated.

One of the Product Owner’s key responsibilities is grooming the Prioritized Product Backlog to ensure the prioritized requirements in the Prioritized Product Backlog to be included in the next two to three Sprints are refined into suitable User Stories. It is recommended that the Product Owner should spend a significant amount of the time in each Sprint for Prioritized Product Backlog grooming. The Product Owner is responsible for adding and revising Prioritized Product Backlog Items in response to any changes and is responsible for providing more detailed User Stories that will be used for the next Sprint.

Grooming helps ensure that refining of requirements and their User Stories is done well in advance of the Sprint Planning Meeting so that the team has a well-analyzed and clearly defined set of stories that can be easily broken down into tasks and subsequently estimated. Based on lessons learned from the current Sprint, there may be changes to requirements, or there may be reprioritization that can be easily incorporated into subsequent Sprints. Grooming supports and enhances the flexibility of the Scrum model by incorporating the latest business and technical insights into future Sprints.

A Product Backlog Review Meeting (also referred to as a Prioritized Product Backlog Grooming Session) is a formal meeting during the Groom Prioritized Product Backlog process, which helps the Scrum Team review and gain consensus about the Prioritized Product Backlog. However, other than the Prioritized Product Backlog Review Meeting, Prioritized Product Backlog grooming should happen throughout the project and can include situations in which the Product Owner writes new User Stories or reprioritizes User Stories in the existing Prioritized Product Backlog, Scrum Team members or Stakeholders give their suggestions about new User Stories to the Product Owner, and so forth.

It is important to note that any item in the Prioritized Product Backlog is always open for re-estimation until the Sprint Backlog is finalized in the Create Sprint Backlog process. After that, changes can continue to be made until immediately prior to the Sprint Planning Meeting, if required.

What is Crystal?

What is Crystal?

What is the “Crystal methodology”?

Introduced by Alistair Cockburn, Crystal Methods, which is a collection of Agile software development approaches, focuses primarily on people and the interaction among them while they work on a software development project. There is also a focus on business-criticality and business-priority of the system under development. Unlike traditional development methods, Crystal doesn’t fix the tools and techniques of development, but keeps people and processes at the core of the development process. However, it is not only the people or the processes that are important, rather the interaction between the two that is most important.

In Cockburn’s words, “Crystal is a family of human-powered, adaptive, ultra light, ‘stretch-to-fit’ software development methodologies.” (Alistair Cockburn;http://alistair.cockburn.us/Crystal+methodologies.)

So, what does “human-powered, adaptive, ultra light, ‘stretch-to-fit’” mean?

  • Crystal is “human-powered”—This means that people are the most important aspect of Crystal, and all the processes and tools are relative to them. Crystal believes that software development is essentially a human activity, so people involved in this activity are vital while the processes should be modelled to meet the requirements of the team, not the other way around. Crystal emphasizes that development teams are self-sufficient and self-organizing, so they are capable of streamlining the processes as the development process progresses and become more organized and competent.
  • Crystal is “adaptive”—First of all, it should be remembered that Crystal is not a set of prescribed tools and techniques for software development; rather, it is an approach. So, the processes and tools are not fixed, but have to be adjusted to the requirements  and characteristics of the project. In other words, Crystal is a “stretch-to-fit” methodology, because each project is unique and require methods that suit the business requirements and that satisfy the technical requirements of the project.
  • Crystal is “ultra light”—Crystal is known as a “lightweight methodology.” This is because Crystal doesn’t advocate too much documentation, overhead management and reporting. Instead, it believes in keeping things light and focusing on developing business-valued and functional software. For this, teams following the Crystal approach work toward enhancing free and open communication among  team members as well as establishing transparent flow of information between developers and stakeholders.

How does Crystal operate?

As stated above, Crystal is not a set of prescribed development tools and methods, but a family of various development approaches. At the beginning of the project, the processes and tools are not fixed but are decided by considering the business requirements and technical needs of the project. When deciding whether Crystal is the right methodology for a project, consider comfort, discretionary money, essential money and life along with the size of the team working on a particular project. Various methodologies in the Crystal family are known as the various “weights” of the Crystal approach and are represented by different colors of the spectrum.

Therefore, the Crystal family of methodologies consists of the following variants: Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond and Crystal Sapphire

To clarify, Crystal Clear is more appropriate for comparatively short-term projects being managed by a team of six developers working out of a single workspace, whereas Crystal Orange is suited for projects that require a team of 10 to 40 members and have a lifespan of 1-2 years. On the other hand, Crystal Sapphire or Crystal Diamond methods are used in large projects that involve potential risk to human life. Therefore, the weight of the Crystal methodology is determined by the project environment and the team size.

What are the main practices recommended by Crystal?

Crystal is precise about certain practices because these are crucial for the successful implementation of the Crystal approach onto any project. These practices include:

  • An iterative and incremental development approach—The projectis developed in iterations that are generally time boxed. The feature delivered at the end of an iteration is integrated into the overall system. User feedback taken at the end of an iteration is used to plan the next iteration; and, new and additional features are added in every subsequent iteration. All this results in refinement and completion of the overall software.
  • Active user involvement—This is a must because Crystal is a people-centric approach and emphasizes transparency. So, users are not only actively involved but also regularly informed about the progress of the project.
  • Delivering on commitments—The team endeavors to ensure frequent delivery of client-valued, potentially-shippable functionalities. It is to this end that Crystal follows an iterative and an incremental development approach.

What are the roles prescribed by Crystal?

The Crystal approach defines a number of roles: Project Sponsor, Senior Designer/Programmer, Designer/Programmers (Business Class Designers, Programmers, Software Documenters and Unit Testers) and Users. Also, there are a number of other roles such as Architect, Coordinator, Requirements Gatherer, Business Expert, Business Analyst/Designer, Project Manager, Design Mentor, Usage Expert, Lead Design Programmer, UI designer, Technical Facilitator and Technical Writer.

Opening for Scrum Master – Panama City, FL

Opening for Scrum Master – Panama City, FL

Jeanette Kelnhofer Deatherage

I work for the Panama city Workforce Center. One of our employers that we post for is looking for a Scrum Master. Its great pay and a wonderful growing company. If you have anyone who may be interested in moving to the Panama City, FL area, please have them send me a resume to deatheragej@workforcecenter.org thank you! Jeanette Deatherage

Scrum Master

Job Description

Contribute to the full agile life cycle of software products in a fast growing software firm.  This position requires a servant leader to facilitate one to many scrum teams across a wide variety of software systems and components for the medical field, specifically in the area of medical device integration with various hospital admissions systems, inter-program and network communications, patient data collection and reporting, and databases access.   Required to be a US citizen or existing US work Visa, and must be willing to work out of our Panama City, FL office.

Responsibilities

This position will report to the Product Development Manager, will be expected to be product knowledgeable, and be responsible the following duties across one or more scrum teams.

  • Overall

o    Must be self-motivated and capable of managing multiple priorities and tasks

o    Serve a liaison between technical and non-technical departments

o    Communicate with other management, developers, product managers and technical support specialists on product issues

o    Must be a team-player with a keen ability to work within collaborative environments

  • Support the product development process

o    Organize and facilitate project planning, daily stand-up meetings, reviews, retrospectives, sprint and release planning, demos and other scrum related meetings.

o    Track and communicate team velocity and sprint/release progress

o    Rigidly maintain Quality System Records and other quality system documentation

o    Manage Release Patch activities that require high alert response, monitoring, and special release cycles.

o    Ensure the development teams are practicing core agile principles of collaboration, prioritization, team accountability, and visibility.

  • Support the Product Owners

o    Assist as needed with backlog maintenance

o    Assist with internal and external communication, improving transparency, and propagating information.

o    Assist with prioritization and resolution of defect and bugs

  • Support the Product Delivery Team

o    Assist team with making appropriate commitments through story selection and task definition.

o    Participate proactively in developing and maintaining team standards, tools, and best practices.

o    Identify and remove impediments, and prevent distractions.

o    Facilitate discussion and conflict resolution.

o    Maintain meetings to time-boxed allocation

o    Empower teams to self-organize

Required Experience

Software development experience in full life cycle software development environments and working experience in an Agile practices environment is a must.  Consideration will be given to candidates with experience in healthcare information technology, preferably with a hospital background or software vendor that markets its products to hospitals.  Experience in clinical workflow, medical devices, or systems integration is also plus.

  • Scrum Master experience in a software development environment.
  • Excellent interpersonal skills, ability to work with diverse personality types.
  • Ability to understand technical issues at a high to intermediate level.
  • Thorough understanding of agile software development methodologies, values, and procedures.
  • Thorough understanding of the software development lifecycle.
  • Proven ability to work independently with limited supervision and with other department personnel.
  • Ability to coach team to reach their highest potential.
  • Must be collaborative in driving decisions.
  • Must be a team-player.
  • Adequate discipline and professionalism to work diligently within published FDA device regulatory guidelines and rigorously follow internal Standard Operating Procedures, including exhaustive documentation of the design and operation of all software produced.
  • A strong attention to detail and a passion for excellence.
  • Excellent written and English verbal communication skills are necessary.
  • Exceptional communication, organization, and time management skills.
  • Ability to deal with multiple projects and deadlines.

Preferred Experience

  • Experience using Rally
  • Experience working under FDA regulatory guidelines
  • Certified Scrum Master
  • Programming experience with either C++, C#, or Java.  Knowledge or experience with MS SQL.

Education

  • A Bachelor’s degree in Computer Science or related discipline is required or equivalent work experience and technical training.

Common Scrum Pitfalls

Common Scrum Pitfalls

Scrum is a highly viable software development methodology, and the teams implementing Scrum seldom experience failure. However, it would be wrong to assume that Scrum is a panacea for all sorts of problems and impediments surfacing during the development process. As a matter of fact, if the team implementing Scrum fails to deliver, Scrum is not to be blamed as a process by itself never goes wrong; instead, the shortcomings and flaws lie in the implementation of that methodology. To put this in other words, there are a number of pitfalls that a Scrum team can fall into as a result of which things can go haywire and the whole purpose of implementing Scrum can be defeated. Some of the common Scrum pitfalls are mentioned below:

  1. Excessive Up-front PlanningScrum teams should not indulge in up-front planning; rather, the team should begin coding and development straight away. There is no point in wasting time on deciding the Product Backlog much in advance as the feedback gathered during Sprint Reviews and Retrospectives is important in planning the subsequent sprints.
  1. Focus On Tools – Tools are not important; people and processes are. So, there is no need to worry about tools. ‘Finding the appropriate tool’ is just an obstacle to getting started, so the teams should start with the development right away.
  1. Problem-Solving in the Daily Scrum – Daily Scrum is neither for discussing problems nor for finding solutions to those problems. Daily Scrums should essentially be time boxed to 5 minutes and be limited to answering the three questions.
  1. Management or Stakeholders managing the team – Scrum requires teams to be self-organizing and self-managing; therefore, neither the management nor the stakeholders should try to manage the team or should assign them work. On the other hand, the team too should not wait for either the Project Manager or the Team Lead to delegate the tasks to the team members.
  1. Scrum Master As a Contributor – Scrum Master is a specialized role; a Scrum Master is supposed to be watcher and a facilitator, not a developer or a tester. So, he should not be assigned any other duty. Also, he should not direct the team in what to do and what not to do as this would distract him from monitoring whether or not the team adheres to the Scrum principles.
  1. Imposed Deadlines and Resources – Scrum teams know best what to complete in a particular Sprint, so neither the stakeholder nor the management should try imposing deadlines or prescribing resources as this would not only demotivate the team, but also reduce their productivity and the quality of the software produced.
  1. Distributed Team – Scrum prefers collocated teams as distribution of team members impedes direct and open communication which in turn reduces productivity and quality.
  1. Product Owner Doesn’t Show – Presence of the Product Owner in Daily Scrums and Retrospectives is essential as he is the bridge between the technical team and the stakeholders. Since feedback given during the Retrospectives is important in planning the succeeding sprints, the Product Owner’s presence is vital.
  1. Stretch Goals – Since Scrum follows the iterative and incremental model of development, the team pre-decides what to do in a Sprint. As such, neither the management nor the stakeholders should try to overload the team with more work as this will result in decreased efficiency and in increased resentment.
  1. Individual over Team – Scrum believes in the dictum that Scrum team swims or sinks together. So, individuals should not try to work beyond their prescribed roles. Overtime as well as individual heroics should be discouraged.
  1. Fixing problems over restarting the Sprint – Failure in immediately restarting the Sprint is one of the major pitfalls. This happens because the team makes itself busy in fixing problems surfaced in the previous as a result of which the project gets extended beyond the stipulated time.
  1. Product Owner Specifies Solutions – Problems are bound to surface during the development process; however, the team, not the Product Owner should come up with the viable solutions to such problems. This is because the team is well versed with the technical aspects of the software under development.
  1. Compromising On Quality – Delivering a high-quality, business valued, and potentially-ship-able product is the very foundation of Scrum; however, many teams tend to give up on quality due to limited resources or due to pressure to release features. This is one of the most common Scrum pitfalls.
  1. Ceasing to learn – Scrum believes in evolutionary development, and this requires constant learning on the part of the team members; however, the team members cease learning and acquiring knowledge about the processes and techniques. This is because they assume that they have come to know all that there is to be known about this methodology.
  1. Frequently reconstituting Scrum team – A scrum team should comprise of experts in order to make it a high-performing team that delivers quality products. Practically speaking, it is very tedious and difficult to form such a team. So, shifting members frequently not only brings down efficiency and productivity but also demotivates the team members. Plus, this is wastage of precious time.

The above discussed points are the common pitfalls that a Scrum team can fall into; however, there can be number of other pitfalls as well since Scrum is a highly flexible methodology and software development is quite a dynamic activity. Whatever may be the scenario, Scrum teams can avoid such pitfalls if they adhere to Scrum principles as closely as possible.