What is "just enough" documentation?

The purpose of documentation is communication. It's a way to communicate to the team working on the product and future teams working on the product. Too little or too much documentation, and the communication breaks down. The right level of documentation is based on how effectively the team communicates and the overall velocity (user stories being completed).

Recently we asked a team to include a screen mockup and user experience diagram as part of the definition of ready. With these diagrams, we noticed developers spending less time estimating, planning, developing, and testing. To the typical Agile practitioner, this was the completely wrong approach, and just having a conversation would be good enough. However, discussions were more efficient with the diagrams as developers spent less time understanding the user story. The team achieved a greater velocity.

You had a thousand pages of stuff to go through, right? Not so much. A screen layout and a user experience diagram were displayed on a single page— basically, two pictures. Pictures are were worth a thousand words. Ask the question: How can you best communicate to move the product development forward quickly and efficiently? communicate to move the product development forward quickly and efficiently?

Who Controls the Agile process?

This question is referring to who has the authority to modify the Agile process for the team. Our response: The team itself controls the scrum process. These are the core tasks teams need to perform: plan, produce, test, release, and improve. These concepts are handled in Agile events like sprint planning, demos, releases, and retrospectives.

Our answer makes organizations a bit uncomfortable. There is concern that teams would skip events like sprint planning and retrospectives. Our advice is to form a basic framework of events for each sprint but not to dictate the step-by-step tasks to conduct those events. A balance is created by giving teams self-direction while ensuring the completion of core Agile events.

The object of any team is to work effectively with a high velocity. Teams are comprised of individuals who have unique working styles. Individuals can approach Agile events differently, which causes the team to work together in unique ways. The self-managed team is an essential pillar of Agile that creates more productive teams. Retrospectives help the team to improve and change to work together more effectively.

How is the Length of a Sprint Determined?

The sprint's purpose is to create the cadence or frequency of all the scrum events. Sprints will need to be long enough to ensure rapid feedback from customers and a continuous cycle of releases. Sprints need to be long enough for the team to achieve their goals for the sprint. Reviewing the development process and typical user stories are also essential inputs into the decision. Sprints are typically 2-weeks but could take up to 4-weeks. Check your velocity. If your velocity shows you are completing more user stories with high quality in a single sprint, then the sprint length is set correctly.

Can the development team produce a stable product for release within the sprint?

Large ERP, SaaS, and highly integrated complex systems make shorter sprints difficult due to the number of teams involved in adding new functionality or a change. A longer sprint gives teams more duration to coordinate with each other and finish work consistently for demo and review.

Is the product highly regulated?

Products that require government regulator approvals or significant oversight by external bodies (auditors) need longer sprints to allow time for approvals.

Is the right level of quality achieved during the sprint?

If poor quality is a common occurrence, additional development and testing time can improve the quality before demos and releases into production.

Is the majority of the product development or configuration outsourced?

Your sprint timeline and duration needs to align with the sprint cycle of the external product development teams.

What's the difference between a Persona and Anti-Persona?

A Persona is the crafted archetype or representation of the customer that will use, buy, or interact with your product. A persona is fictitious and often is a composite of several customers rolled into one. The Persona helps the team understand the customer and guides design decisions.

An Anti-Persona is similar to a persona in that it is also a fictitious composite of a customer archetype. The Anti-Persona helps the team understand the customer they DO NOT want and also helps guide design decisions.

Why bother with the Anti-Persona? It's about creating Context around your product. Your product is focused on the customer you want and the customer you don't want. By contrasting the two personas, you create a more precise line or border around your customer used for design decisions. You're making a more holistic and focused context, which drives better design choices for the product.

How would you define the term context? Although Context is often compared to scope management for projects (IN scope and OUT of scope), Context is used in many different ways, not just with personas and project scope. Context creates a center point, focus, or target by contrasting both negative and positive points. Pros versus cons, the good and the bad, circles and soup, and what drives us forward and what drives us backward are examples of techniques that utilize Context.

Join the Global Coaching community today for live online discussions, questions answered by coaches, and discuss with other professionals world-wide.

What is a tech card, and how does it work?

Tech cards are "enabler cards." Tech Cards are used to set aside time for the team to perform research, investigation, feasibility, prototyping, and other actives during a sprint that enables a card to be developed. Tech Cards can take an entire sprint to complete. Tech cards are not used for activities less than 4 hours and don't replace or represent events like sprint planning or demo. Tech cards don't exist independently and have a relationship with a specific user story or set of user stories.

The Tech card is used to set aside a certain amount of time or points for the team to research or prototype a solution before developing it. Tech cards are associated with a specific card or user story, but they can be associated with multiple cards or user stories. Tech cards give the team a path to complete the card or user story.

Update the related user story as needed. Based on the Tech Card outcome, the acceptance criteria of the related user story may require adjustment and a reset of expectations between the team and the customer. This is especially true of, "We can solve this, but not in the way you originally expected." Expectations, acceptance criteria, and estimations typically require a discussion with the team and are often changed.

Join the Global Coaching community today for live online discussions, questions answered by coaches, and discuss with other professionals world-wide.

How much time should you set aside for sprint planning?

Sprint planning is an event that establishes the development goal with a prioritized and estimated list of cards or user stories to be completed in the sprint. Sprint planning is performed with the team and creates consensus.

The development goal is what the team plans to accomplish in the sprint.

The sprint backlog is a list of backlog items the team has agreed to work on in the upcoming sprint.

It is suggested Sprint Planning takes 4 hours or less for a 2-week sprint; however, large complex and highly integrated systems may require more planning time. The prerequisite for a successful sprint planning event is a well-groomed backlog, with each card having clear attainable acceptance criteria. Clarity reduces the amount of time spent on conversation and contributes to less time spent on Sprint Planning.

Join the Global Coaching community today for live online discussions, questions answered by coaches, and discuss with other professionals world-wide.

Does a Business Analyst Design in Agile?

It depends on the level of design. There are different levels of design:

Strategic: At a satellite in orbit level. Strategy design creates an overall design for the entire product. Strategy design crosses all Agile teams in your organization. The purpose is to determine the desired product capabilities. Then break down those capabilities into smaller features that can be worked on by individual teams. The Business Analyst is actively engaging the business on long term strategy, market trends, product positioning, funding, organizational change strategies, building consensus with management, and more. The Business Analyst deconstructs the strategy design into smaller components for team-based high-level planning.

High-Level: This is performed at the team level to align the Strategy design with the team's work. High-Level planning is around systems or processes within the team's control. The Business Analyst works with the Product Owner to deconstruct the strategy design into a high-level design specifically for the individual team.

Detailed: In-depth design or technical design to create a solution for the card or user story. Technical leads and Developers are actively designing, developing, coding, configuring, and testing the solution. The Business Analyst provides consulting support to development teams.

Join Global Coaching today and get practical insight from the Uncommon Coaches.

Is a PM or BA Better for the Role of Scrum Master?

An organization was transitioning from traditional waterfall roles to Agile roles. The organization had Project Managers, Business Analysts, Developers, Development Leads, Quality Assurance, and Release Management.

The organization's thought process was to take a traditional role and move it into the new Agile role. PMs become Scrum Master, and BAs become Product Owners. Easy, right? Maybe not. The transition quickly ran into difficulties and frustrated team members.

Here's a more collaborative and hybrid approach:

Determine the roles you need. Agile has a standard set of roles like Scrum Master and Product Owner. Do you need additional roles? Do you need a Business Analyst to help the Product Owner strategically put together a product roadmap and story map based on market research, benchmarking, and other factors? Does the organization have a strong need for a formal change and release process? Not all Agile teams have the same roles. Some teams have more roles than other teams because of their specific needs (such as compliance, legal, and regulatory.)

Formulate how your Agile teams will cover your development needs. How many teams? What product, service, or process will that team cover? How are they connected to other teams? What roles would the team need? The object is to determine the number of slots available for each role on all the teams.

Give all team members a high-level overview of the Agile roles and how they work. The overview presents the traits and tasks of a good Scrum Master, Product Owner, and other roles in Agile.

Ask team members where they would like to go with their career. Let team members choose multiple lanes.

Look for fit. Talk with team members about their experience and skills in a non-confrontational way. Ask team members about where they see their career headed. Let team members choose multiple roles with the first choice, second choice, and third choice.

Assign team members to open slots of roles. Communicate role assignments and start the process of putting together a transition plan for each team member. How will they move from their current role to the new role?

Train team members on their new Agile role in-depth. Go deep in training on skills and techniques needed to be successful. Provide coaching from a coach that understands your organization's structure and why you have typical and non-typical roles. Avoid coaches that are inflexible and unwilling to adapt to your organization's needs.

Join Global Coaching today and get practical insight from the Uncommon Coaches.

Should You Go Back and Change a User Story?

Should you go back and change a user story if the development is different than expected? If the solution to the user story is not what is expected, the acceptance criteria will need to change. The user story itself typically doesn't change. Here's an example:

As a Producer, I need podcast audio files published on our schedule so that the Podcast Service can ad revenue-generating advertising valued at $150k per month to the audio files.

Not the best user story, but let's get some background. The Producer was expecting to publish the podcast files on a schedule of their choosing, but the Podcast Service maintains the publishing schedule independent of the Producer's desired schedule.

See the conflict? The Producer wants to control the schedule and publishing of podcasts, but scheduling and publishing are controlled entirely by the podcast service. It's impossible to send a date and time for publication to the podcast service because that service doesn't accept that data when transmitting the files.

The original acceptance criteria called for a date and time to be passed with the podcast audio files to the podcast service. The podcast service doesn't accept anything other than the audio files themselves. In this case, the acceptance criteria will have to change.

The Product Owner will need to go back to the Producer and explain the Podcast Service's limitation. The Producer may pull the card entirely because it no longer provides the expected business value.

Engaging an architect or expert on the Podcast Service system during the product roadmap or user story map planning might have avoided the development team's inability to complete the card as expected. The card needed more refinement before moving into a sprint. Agile is about having open conversations frequently throughout not only during the sprint but prior to the sprint.