Key Operations Overview
Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.
The authors of the Agile Manifesto chose “Agile” as the label for this whole idea because that word represented the adaptiveness and response to change which was so important to their approach.
It’s really about thinking through how you can understand what’s going on in the environment that you’re in today, identify what uncertainty you’re facing, and figure out how you can adapt to that as you go along.
Agile software development is more than frameworks such as Scrum, Extreme Programming, or Feature-Driven Development (FDD).
Agile software development is more than practices such as pair programming, test-driven development, stand-ups, planning sessions, and sprints.
Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.
One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.
There’s a big focus in the Agile software development community on collaboration and the self-organizing team.
That doesn’t mean that there aren’t managers. It means that teams have the ability to figure out how they’re going to approach things on their own.
It means that those teams are cross-functional. Those teams don’t have to have specific roles involved so much as that when you get the team together, you make sure that you have all the right skill sets on the team.
There still is a place for managers. Managers make sure team members have, or obtain, the right skill sets. Managers provide the environment that allows the team to be successful. Managers mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues.
When most teams and organizations start doing Agile development, they focus on the practices that help with collaboration and organizing the work, which is great. However, another key set of practices that are not as frequently followed but should be are specific technical practices that directly deal with developing software in a way that helps your team deal with uncertainty. Those technical practices are essential and something you shouldn’t overlook.
Ultimately, Agile is a mindset informed by the Agile Manifesto’s values and principles. Those values and principles provide guidance on how to create and respond to change and how to deal with uncertainty.
You could say that the first sentence of the Agile Manifesto encapsulates the whole idea: “We are uncovering better ways of developing software by doing it and helping others do it.”
When you face uncertainty, try something you think might work, get feedback, and adjust accordingly.
Keep the values and principles in mind when you do this. Let your context guide which frameworks, practices, and techniques you use to collaborate with your team and deliver value to your customers.
If Agile is a mindset, then what does that say about the idea of Agile methodologies? To answer this question, you may find it helpful to have a clear definition of methodology.
Alistair Cockburn suggested that a methodology is the set of conventions that a team agrees to follow. That means that each team will have its own methodology, which will be different in either small or large ways from every other team’s methodology.
So Agile methodologies are the conventions that a team chooses to follow in a way that follows Agile values and principles.
“Wait,” you’re probably saying, “I thought Scrum and XP were Agile methodologies.” Alistair applied the term framework to those concepts. They certainly were born from a single team’s methodology, but they became frameworks when they were generalized to be used by other teams. Those frameworks help inform where a team starts with their methodology, but they shouldn’t be the team’s methodology. The team will always need to adapt its use of a framework to fit properly in its context.
As Agile Software Development became more popular, people involved with software development activities but who didn’t personally develop software looked for some way to figure out how these Agile ideas applied in their line of work.
The Agile Manifesto and the 12 Principles were written by a group of software developers (and a tester) to address issues that software developers faced. When you think of Agile as a mindset, that mindset can be applied to other activities.
When you do that, Agile becomes an adjective. It describes how you perform some activity. It does not create a new methodology for the reasons explained above.
When you want to understand Agile project management, ask “How might we perform project management in a way that allows us to create and respond to change and deal with uncertainty?” Agile Alliance and Project Management Institute (PMI) explored this question through a joint effort to create the Agile Practice Guide (Available to Agile Alliance Members).
When you want to understand Agile business analysis, ask “How might we perform business analysis in a way that allows us to create and respond to change and deal with uncertainty?” Agile Alliance and International Institute of Business Analysis (IIBA) explored this question through a joint effort to create the Agile Extension to the Business Analysis Body of Knowledge (Available to Agile Alliance Members).
The two concepts noted above are examples of an attempt to move Agile “outside of software.” Those efforts have resulted recently in the Business Agility movement.
If you extend the idea of Agile as a mindset, then people seeking Business Agility ask themselves, “How might we structure and operate our organization in a way that allows us to create and respond to change and deal with uncertainty?”
You might say that business agility is a recognition that in order for people in an organization to operate with an Agile mindset, the entire organization needs to support that mindset. Agile software development was never truly Agile until the organization changed its structure and operations to work in an uncertain environment.
In consultation with the customer or product owner, the team divides up the work to be done into functional increments called “user stories.” Each user story is expected to yield a contribution to the value of the overall product.
Each day at the same time, the team meets so as to bring everyone up to date on the information that is vital for coordination: each team members briefly describes any “completed” contributions and any obstacles that stand in their way.
When the project calls for it – for instance when user experience is a major factor in project outcomes – the team crafts detailed, synthetic biographies of fictitious users of the future product: these are called “personas.”
A “team” in the Agile sense is a small group of people, assigned to the same project or effort, nearly all of them on a full-time basis. A small minority of team members may be part-time contributors, or may have competing responsibilities.
Nearly all Agile teams favor an incremental development strategy; in an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality.
Agile projects are iterative insofar as they intentionally allow for “repeating” software development activities, and for potentially “revisiting” the same work products.
Once a project has been underway for some time, or at the end of the project, all of the team’s permanent members (not just the developers) invests from one to three days in a detailed analysis of the project’s significant events.
"We are uncovering better ways of developing software by doing it and helping others do it." Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
"That is, while there is value in the items on the right, we value the items on the left more."
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly..
User stories are the list of functions that a product does, whether it is a mobile app or a website. User stories are one of the main methods of control in Agile, for example, Extreme Programming (XP) features such processes as continuous planning (from Scrum) and customer involvement that are the necessary parts of user stories creation.
A user story answers the following questions:
- who?
- does what?
- does it get what?
“Who” is an actor who stands for a website or a mobile app user. This user is either a guest or a developer/product admin.
“Does what” is an action the user does in order to reach his / her goal.
“Does it to get what” is the user’s goal of interaction.
For instance, a website visitor (who) may want to fill in a contact form (does what) to get in touch with a company regarding a project (goal).
I advise you to separate all actors into the groups: a target audience, the main group, the group of secondary importance, and others. After this action, you should give unique names to all actors from the groups. Then you need to write stories from the perspective of these actors, indicating their unique names. It will help you to realize which stories are necessary only for the actors from the target audience, which stories are necessary for each group. You will be able to build a priority more correctly since the stories of the actors of the target group are more important for us.
Such user stories are better to write on the small sticky pieces of paper and keep within a reach of eyesight while developing. If there are many user stories it’s strongly recommended to keep the user stories in the electronic device.
You can use the user stories online tools such as Online Visual Paradigm, Realtime Board, StoriesOnBoard. These services are a way to organizing stories that gives a broader context and helps in planning releases, in other words, these tools of user stories mapping.
The most important part of the user story is a goal. The goals are actions that the company wants its target audience to perform. If the company doesn’t understand which processes lead to these main actions, so the product won’t work properly.
Let’s expand on the reasons why we should pay attention to user stories.
As was said before user stories are a list of product functions. If a client doesn’t know exactly how a product should work, the user stories are to help to comprehend. If the client has an idea of the product’s work and the list of specs, a development team must anyway hold a meeting regarding a vision of the product. The client and the team should be on the same page about goals of product development and ways of achieving these goals. Otherwise, misunderstanding can happen and a developer will create a feature nobody actually needs. Time loss, budget loss.
The user stories are aimed at:
- delivering a product that the client really needs;
- budget estimation;
- time estimation;
- saving time on coding and giving clear tasks to developers;
- UI design.
The user stories writing is a great service to offer to the client. If the client doesn’t have time for the user stories and for defining so-called “use cases”, the development team in general and internet marketer, in particular, can deliver this service.
The mentioned term “use cases” is the scenario that users are likely to follow when using the product. They give a general overview of the product. For example, one can use Facebook for reconnecting with mates and another for doing business.
The user stories clarify and detail how these use cases are implemented in terms of user actions.
User stories writing involves several parties: a client, a development team, and customer representatives. It’s necessary that everybody stays in touch permanently. If the client doesn’t have time for a constant involvement, this role can be reassigned to the Product owner (in Scrum) or to an internet marketer from either a client or a developer side. Anyway, the client / stakeholder must revise these stories since he/she is the only person who knows a product market best.
A user story answers the following questions:
- who?
- does what?
- does it get what?
The formula for the good user story looks like: “I am as a user (role) want to (action) in order to (goal)”.
Bear in mind, that there could be several roles and then you have to write the user story for all the roles separately. Let’s imagine a situation when somebody wants to fill in the contact form. It is a user with an account we have one story, and if it’s an anonymous user - the story is different.
The user stories are written at all the development stages: before development, while shaping a product idea, during development itself, especially when a developer finds out that the story is actually an epic (large user story), and at the release stage for the reason that there could be unexpected difficulties during the transition.
A good user story matches the following model called “INVEST” created by Bill Wake:
- Independent. Reduced dependencies = easier to plan;
- Negotiable. Details added via collaboration (with all parties mentioned above);
- Valuable. Provides value to the customer;
- Estimable. Too big or too vague = not estimable;
- Small. Can be done in less than a week by the team;
- Testable. Good acceptance criteria.
Use a rule of thumb to estimate a story’s size: if any single story takes more than 50% of an iteration (2 weeks/10-days sprints) it should be broken into substories.
The last criteria are tricky enough, too. Let’s see what would be an acceptance criterion in the example given earlier.
“An anonymous website visitor wants to fill in a contact form to get in touch with a company regarding a project”.
The acceptance criteria here would be a possibility to fill in and send the contact form. Developers and clients could add extra technical criteria. Say, the user can be allowed to submit up to N contact forms a day.
- Write user stories engaging the whole “team” which consists of a product manager/client/stakeholder or even end-users of your product.
- Start writing stories from epics and then break them into smaller stories step by step.
- Identify user stories with numbers or letters.
- Indicate how much time is allocated for this story.
- Indicate priority, if needed. If a client needs to release a high fidelity prototype soon, put the highest priority to the main functions. Use cases will help you to find out which user stories form the base of the product.
- Clarifying user stories from a technical point of view (do not include technical features in the story!), for example, how the product’s bugs should be displayed and processed. Usually, it’s a product owner who sets technical requirements and acceptance criteria.
- Using epics for tasks. Break them into substories.
- Using the stories that were not approved by a customer group representative. Hold focus groups, ask for a consultation.
- Disaggregating low priority epics into user stories. The chances are that it will be a waste of time.
- Including technical requirements.
- Making approximations about a target audience.
As a <user> I want <function> so that <value>.
Above is a very simple user story template. How can something so simple be so hard to get right? User stories make up the heart of agile development. They are the primary input to the team. The team takes the user stories and creates product increments based on completing those stories. Unfortunately, getting user stories “right” is difficult to do right away. The Product Owner (or other product facing role) needs to learn how to create user stories which meet the needs of the team. This is a skill which can be learned over time, but I’m about to save you a bit of learning curve.
In order to create good user stories, start by remembering to INVEST in good user stories. INVEST is an acronym which encompasses the following concepts which make up a good user story:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
Let’s cover each of them with a simple explanation.
Stories should be as independent as possible. When thinking of independence it is often easier to think of “order independent.” In other words, stories can be worked on in any order. Why is this important? It allows for true prioritization of each and every story. When dependencies come into play it may not be possible to implement a valuable story without implementing other much less valuable stories.
A story is not a contract. A story IS an invitation to a conversation. The story captures the essence of what is desired. The actual result needs to be the result of collaborative negotation between the customer (or customer proxy like the Product Owner), developer and tester (at a minimum). The goal is to meet customer needs, not develop something to the letter of the user story if doing so is insufficient! Remember, you can always ask the magic question to help drive the conversation.
If a story does not have discernable value it should not be done. Period. Hopefully user stories are being prioritized in the backlog according to business value, so this should be obvious. Some people say each story should be valuable to the customer or user. I don’t like that way of thinking because business value encompasses more than just customer or user facing value. It includes internal value which is useful for things which are normally called “non-functional requirements” or something similar. I prefer to say the story has value to the “user” in the user story. In this way it is clear who is to be satisfied. Finally, remember the “so that ” clause of the user story. It is there for a reason – it is the exact value we are trying to deliver by completing the story!
A story has to be able to be estimated or sized so it can be properly prioritized. A value with high value but extremely lengthy development time may not be the highest priority item because of the length of time to develop it. What happens if a story can’t be estimated? You can split the story and perhaps gain more clarity. Sometimes splitting a story doesn’t help though. If this situation occurs it may be necessary to do some research about the story first. Please, please, please timebox the research! If you do not, it will take all available time thereby depriving the product of something else which could have been done instead.
Obviously stories are small chunks of work, but how small should they be? The answer depends on the team and the methodology being used. I teach agile and suggest two week iterations which allow for user stories to average 3-4 days of work – TOTAL! This includes all work to get the story to a “done” state. Also remember not to goldplate user stories. You should do the simplest thing that works – then stop!
Every story needs to be testable in order to be “done.” In fact, I like to think of testable meaning acceptance criteria can be written immediately. Thinking this way encourages more collaboration up front, builds quality in by moving QA up in the process, and allows for easy transformation to an acceptance test-driven development (ATDD) process. As with negotiable above, asking the magic question can help ensure the user story is testable as well.
“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements“
Story Points are intended to make team estimating easier. Instead of looking at a product backlog item and estimating it in hours, teams consider only how much effort a product backlog item will require, relative to other product backlog items.
Ok, so it makes estimating easier but how is that useful? Story Points are of no value whatever to a business because they can’t be used to predict cost or delivery dates. Even the Scrum team cannot make any predictions as to how many Story Points it can complete in a sprint (velocity) until it’s got a few sprints under it’s belt, some months down the road.
For hundreds of years we’ve had standard units of time. Why can’t we use hours or days? Well, in a nutshell, because your hour is not the same as my hour.
If you ask two developers to estimate the same task, you’ll get two different answers. While some of the difference might be explained by gaps in the specification or understanding, the fact is that developers have different knowledge and experiences so it will take more or less time to do the same work.
Ask those same two developers to rate the amount of effort required to complete one product backlog item relative to another product backlog item and you’re far more likely to end up with a consensus.
So, up until now, you may have been unconvinced about the need to use Story Points. Ok, they show the relative effort to complete work on different product backlog items but how does that help anything? Until we understand what the team’s velocity is, we still can’t predict when product backlog items are likely to be completed. Worse, if the membership of the team changes, the velocity will change and we won’t know what that new velocity is until some time down the road.
But to try and match Story Points to hours is missing the point. What’s important is how many Story Points a team can complete in a sprint, known as the velocity. When you know this, you can make some predictions and you know what, they’re likely to be good. Very good.
The real reason for using Story Points is that they’re accurate
Chances are that you’ve had the experience of being given an estimate that turned out to be completely wrong—the car wasn’t repaired in two days or the table at the restaurant wasn’t ready in 15 minutes.
If estimates can be inaccurate, why are they important to project planning?
It’s a matter of setting the right expectations and determining how much work is realistic to complete in a given timeframe—teams need to account for a project’s complexity in order to decide the amount of effort required, the number of resources needed, and ultimately, how much time it will take to complete the project.
Many developers in Agile environments have successfully improved the estimation process using the Fibonacci scale or a modified Fibonacci sequence to estimate the work that needs to be completed in an iteration.
Learn what the Fibonacci sequence is and how you can apply it to Agile estimations.
Fibonacci was an Italian mathematician in the Middle Ages who wrote a book called Liber Abaci (Book of Calculation). This book introduced and popularized the Hindu-Arabic numeral system in the Western world. In Liber Abaci, Fibonacci also presented the following problem:
A certain man put a pair of rabbits in a place surrounded on all sides by a wall. How many pairs of rabbits can be produced from that pair in a year if it is supposed that every month each pair begets a new pair which from the second month on becomes productive?
To estimate the answer, Fibonacci introduced an exponential sequence of numbers, now known as the Fibonacci number or Fibonacci sequence. In the sequence, each number is the sum of the preceding two numbers:
0, 1, 2, 3, 5, 8, 13, 21…
Stopping Here For Now
- Practical Studio Information
- Company Strategic Documents
- Dress Code
- Working Hours Strategy
- Personal and Company Devices
- HR Policies
- Management Structure
- Employee Org Chart
- Resource Setup
- Key Operations Overview
- Repository Guidelines
- Project Board Guidelines
- Pull Request Guidelines
- Issue Submission Guidelines