A bureaucrat, considering himself overloaded, hires two subordinates to do his job. He can’t share it with his already working colleagues, nor can he hire one subordinate and share it with him – no one needs competitors. The story repeats as his employees hire employees for themselves. Now seven people are doing the work of one. Everyone is very busy, but neither the work speed nor its quality increases.
**Personas in Agile**
Personas, first introduced by Alan Cooper, define the archetypal user of a system, a representation of the person who will interact with it. The idea is that if you want to develop software, it should be designed for a specific individual. In other words, personas are fictional characters based on your knowledge of real users.
You are probably familiar with actors. Unlike actors, personas are not roles played by people. For example, in a banking application, we might have personas like “Client” and “Credit Card Processor.” Personas are often documented in one or two sentences describing their role. For instance, the description of “Client” might look like this: “An individual or organization conducting business with the bank.”
Personas should be described as if they were real people. They can have names, personality traits, families, jobs, skill levels, preferences, behavior models, and personal relationships. It’s also good practice to write a short “day in the life” story and add images to help the team visualize users.
Quite often, one or two pages of documentation are written for each persona. The goal is to bring your users to life, developing personas with real names, personalities, motives, and often even photos. In essence, a good persona is highly personalized.
You’ll need to develop several personas, perhaps seven or eight for a banking system, to ensure you understand all the needs of your customer base. To write effective personas, you’ll need to conduct some user group research to make sure you genuinely understand your users. You might want to conduct a focus group with potential users, talk to your support staff (support staff often have a good understanding of end-user needs), or talk to product managers whose job is to understand your users.
Personas are incredibly useful when you don’t have easy access to real users because they act as “stand-ins for users,” helping guide your decisions regarding functionality and design. Answers to questions like “How will Max use this feature?” or “Will Nick be interested in this?” can help initiate discussions within your team, prompting you to think the way your users really think. Personas are often used in the creation of web software, such as Amazon or eBay systems. Personas and usage scenarios are highly popular at Microsoft and are one of the artifacts described in their Agile process, Microsoft Solutions Framework (MSF).
In the book “The Inmates Are Running the Asylum,” Alan Cooper suggests the following methods for writing effective personas:
– You don’t “create” personas; you discover them as a byproduct of the requirements discovery process.
– Describe specific personas: by designing for one person, you will do the job much more successfully.
– To understand what your system should and shouldn’t do, you need to understand the goals of the personas.
– If you’ve identified more than three primary personas, your scope is probably too large.
– You need a limited number of personas; your goal is to narrow down the circle of people for whom you are developing the system.
**Task Estimation with Planning Poker**
If you dislike estimating tasks “by eye” and desire precise results, try playing Planning Poker.
Planning Poker is a task estimation technique for Agile teams. It is conducted using cards and resembles a poker game. The method was first described in an article by one of the authors of the Agile Manifesto, James Grenning.
In the Planning Poker estimation method, the entire team, led by the Scrum Master, participates—it’s a crucial condition. The Scrum Master distributes a deck of special cards to all participants. For remote teams, various online services can be suitable, while the estimation rules remain unchanged.
The Fibonacci Numbers are often used, which is a sequence of numbers starting with two ones, and each subsequent number is the sum of the two preceding ones: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89.
The deck may include cards with the following values:
– ? — uncertain answer;
– ½ — simple task;
– ∞ — infinitely long task;
– coffee break or an image of a coffee cup — a break is needed;
– cards with sizes S, M, L, or any others as needed.
Team estimation helps achieve an objective result. For example, a developer might know better how much time their work actually takes but may exaggerate its complexity to hedge and get more time. Therefore, the estimation process is always monitored by the facilitator. The idea is to consider the opinions of all team members and make the most accurate predictions.
If, after the voting, all cards are close in values, the team has estimated the task approximately the same, and it can be concluded there.
But what to do when there are contrasting differences? For example, two developers assessed the task differently: the Junior chose a card with a nominal value of 4, while the Senior chose 10. Ask each to express their opinion and listen to their arguments. You and the rest of the team will understand why they think so. For instance, the Senior may have inflated the number to get more time, although they can work faster. The Junior may have underestimated the task’s complexity due to inexperience. Usually, reality lies somewhere in between. After discussion, repeat the vote, now based on the new information.
If everyone quickly agrees, and you get the desired result, move on to the next task. If not, continue voting until the result becomes unequivocal. Your goal is the arithmetic mean of all estimates proposed by the team.
The Dunning-Kruger Effect, encapsulated in phrases like “Other people’s work always seems easy” or “The more I know, the less I know” (or as Socrates put it, “I know that I am intelligent because I know that I know nothing”), highlights a peculiar aspect of our perception, scientifically termed the Dunning-Kruger Effect.
The Team Competency Matrix is a straightforward tool for determining the set of skills within a team based on specific needs. We can use this matrix to assess whether all the skills required for a project are present or if the team is actively developing them.
In teams, it’s crucial for all members to share their skills with others. Relying solely on one team member possessing a particular skill can be risky.
Imagine a scenario where a team member has an accident; if they are the sole possessor of certain project-critical skills, it could be a genuine catastrophe for the company.
Working with the matrix starts with identifying the skills required for the project and the expectations for each of these skills.
Building this skills matrix is quite straightforward because it is simple and specific. This matrix provides a holistic view of the team’s skill set.
The method of prioritization known as the Walking Skeleton emerged in the early 2000s, championed by Dr. Alistair Cockburn, an expert in agile software development who described it as:
… A tiny implementation of a system performing a small end-to-end function, it avoids using the final architecture but ties together the fundamental architectural components. Subsequently, the architecture and functionality can evolve in parallel.
The Walking Skeleton represents the embodiment of your basic architectural concept. It’s not a mere sketch; it’s a genuinely executable and deliverable product that must be accompanied by tests.
Due to the nature of this method, the Walking Skeleton is utilized to prioritize features in an MVP, determining which ones are absolutely critical for the product to function. Sometimes, the Walking Skeleton may be smaller than a full MVP, but it prioritizes essential features.
How does it work?
All features are laid out in the form of columns, acting as vertebrae, and stories hang down like ribs. This representation visualizes the importance of user stories within specific features and focuses on implementing one set of stories at a time.
Once you’ve established the foundation and listed all your core features, you can start prioritizing stories in each rib. The higher the priority of a story, the closer it is to the backbone, making it more crucial and relevant. Stories towards the end are less important.
After placing the stories, you’ll see the minimal implementation of your product at the top of the “Story Map.” This is what Dr. Alistair Cockburn refers to as the “Walking Skeleton”: a very minimalistic but functional product, typically ready for user testing.
When to use it?
The primary goal of the Walking Skeleton model is to ensure that the MVP eventually “walks,” meaning it works according to requirements. Therefore, when evaluating features using this model, you’ll need to determine the following:
Everything necessary for the system to function.
Features that must be there according to requirements.
Features aligning with business goals and values.
Features that have passed testing.
By choosing and implementing these features, you’ll end up with a func
Kaizen, or 改善 (pronounced kai-zen), represents a Japanese philosophy and practice that centers on the continuous improvement of production processes, development, supporting business processes, management, and all aspects of life.
Are you a project management professional aspiring to soar to new heights in your career? The Project Management Institute (PMI) Certification Framework is your compass to achieving excellence in the dynamic field of project management.
Understanding the PMI Certification Framework:
PMI, a globally recognized authority in project management, offers a structured Certification Framework catering to professionals at various stages of their careers.
The concept of Shu-Ha-Ri comes from the Japanese martial art of Aikido.
Shu (守): The first stage, which means that one must memorize everything exactly as the teacher shows. It requires many years of training, or else there will be no foundation for moving on to the next stage.
Ha (破): The second stage, where the learner reflects on their actions, changes the rules, tries to break them, and builds a new system of their own rules. They also learn new techniques from other teachers. Many try to do this too early, overestimating their capabilities.
Ri (離): The third stage, according to which one needs to free oneself from rules—there are no more rules, only the natural course of things (Dao). “Ri” means to rise above everything that was learned before, to create higher and more general principles.
The Shu-Ha-Ri model can be adapted not only for martial arts but is also an ideal metaphor for Agile team development.
Shu: We strictly adhere to Agile rules. We see that all Agile meetings/ceremonies are conducted, and all rules are followed. For example, the Daily Stand-up does not exceed 15 minutes, and the whole team discusses progress in achieving iteration/sprint goals.
Ha: Now that everyone is familiar with the basic rules, we can begin to improve and make amendments to them. Referring to the example above, perhaps we will review our Daily Stand-ups and change their time, or we will go through each user story instead of listening to each person in turn. Practicing this approach, we can see what works and what doesn’t. Retrospectives will greatly assist us in this.
Ri: We have departed from the “standard” structure and mechanisms and have begun to set our own rules.
The MoSCoW method is a prioritization technique used in many management spheres to achieve consensus on what is most important to stakeholders and consumers.
This term is an acronym, where each consonant letter represents one of the possible priority categories (with the added letters O for better memorization). Thus, priorities are classified as:
Must have – everything under this category is critical and must be included in the product. If something from it is not included, the release is considered a failure. However, this priority can be lowered if there is stakeholder agreement.
Should have – these are important requirements but not critical for the release. These are the first level of “wants,” and generally, in terms of importance, they correspond to Must requirements but are not as time-sensitive.
Could have – these are desirable but optional requirements for the release. Typically, these are inexpensive product improvements. Despite their low importance, this is the second level of “wants.”
Won’t have – these are functional features that are least critical or do not align with the product strategy. They should be set aside or kept in mind for subsequent product releases.