DevOps In 5 letters: Should We Say CALMS or CALMR?
By KnowledgeHut Editor
When someone asks me to explain what DevOps is about, I usually do this using the different letters of the acronym CALMS.CultureCulture is the foundation of DevOps. If you omit culture, you're only doing some symptoms of DevOps (like using a whiteboard, working in timeboxes and doing daily standup meetings won't make you an Agile team).Culture is about the people, about self-organized teams, about T-shaped profiles, about tearing down the wall between Development and Operations. A DevOps team takes end-to-end responsibility of an application or system: "you build it, you run it".If your organization has always been working in a command-and-control style, then the first thing to do is to instill a culture of team empowerment. And don’t underestimate this: this will probably take years to change.AutomationThis is where a lot of focus goes into and can be considered as the easiest to obtain. The heart of DevOps is the CI/CD pipeline: the continuous flow process that is triggered upon check-in of new versions of code. Continuous integration was already known in eXtreme Programming. In a DevOps context, the continuous delivery/deployment makes the story complete. To make your CI/CD pipeline work at its full capacity, you have to consider everything as code:Your source code of courseYour automated tests - unit tests, integration tests and so onYour configurationIncluding your infrastructure configurationYour database changesYour documentationBut automation is also about closing the feedback loop: getting observations, metrics from running system fed back into your team’s product backlog.Lean principlesDevOps is not about moving big chunks of changes to production, but instead, moving to a constant flow of small and easier to control changes. Flow, as in Kanban: limited work in progress, small batches. And moving to the production does not automatically mean: "going live". If there is a dependency with other code that is not yet ready, you can still disable your code via feature toggling until everything is ready to be activated.MeasuringThis is crucial to improving: define metrics on your process. How good are the things going in your organisation? Where is room for improvement? And the apply the typical Plan-Do-Check-Act/Adjust approach to gradually improve your way of working.SharingDevOps teams take full responsibility over their system. But this does not mean that they have to reinvent the wheel over and over again. They learn from their peers.Common senseThere are plenty of resources on the internet - blogs, pictures, slide decks and videos - that explain DevOps using this CALMS acronym. So by now, this acronym has become common sense for anyone who searched for some kind of definition of DevOps. Or hasn't it…?DevOps according to SAFe®, in 5 slightly different lettersRecently I had a discussion with a colleague who is a certified SAFe® Program Consultant and trainer. According to this colleague, SAFe® doesn’t talk about CALMS but about CALMR instead. She wanted to be sure we tell the same story and don’t confuse the people we train and coach. I am not going to give a full explanation of SAFe's definition of Devops, you can read it yourself on the SAFe® site (more specifically on this page www.scaledagileframework.com/devops).But I will briefly explain what the acronym CALMR stands for according to SAFe®:Culture of sharing responsibilityAutomation of continuous delivery pipelineLean flow accelerates deliveryMeasurement of everythingRecovery enables low-risk releasesThis discussion made me wonder: if a large part of the world talks about CALMS to define the principles of DevOps, then why does SAFe® talk about CALMR and what is the difference? And why do they call it "SAFe® DevOps"? So I did some investigation and this is what I found.What's the difference?In all honesty, whether you speak about CALMS or CALMR, in the end, both are equal, or better, equivalent. Let me explain why.In the CALMS acronym, the S stand for sharing. Sharing of knowledge, of experiences. Call it communities, or chapters and guilds if you are more into the way Spotify works. I deliberately don't call it "the Spotify model" because there is no Spotify Model (says Marcin Floryan, a Spotify chapter lead in this presentation: https://www.infoq.com/presentations/spotify-culture-stc).But that’s entirely different story.Sharing in CALMRIn "SAFe® DevOps", sharing is a part of the Culture. People work in teams. But teams together form a release train. So, these teams will not only need to align planning-wise, they also inspect and adapt during the IP sprint. And they learn continuously. OK, fair point. But sharing clearly is there in both definitions.Recovery in CALMSSo, what about the recovery aspect of SAFe® DevOps? Is it a part of the CALMS acronym too? In my opinion, yes, of course, divided over other aspects. The first thing that the SAFe® site tells about Recovery is "Stop the line mentality".Now, that is a Lean principle. Mary Poppendieck (Lean Software Development) mentions this in her presentations: "The greatest productivity comes from not tolerating defects. Create ways to detect defects the moment they occur” (see slide deck https://accu.org/content/conf2007/Poppendieck-Stop_the_Line_Quality.pdf ).The other parts, Plan for and rehearse failure and Build the environment and capability to fix forward and roll back, these are typically automation aspects. Plan for and rehearse failure talks about the chaos monkey.The Simian Army is a bunch of tools and concepts that will create chaos in your ecosystem: kill processes, slow down processing and so on. Chaos engineering is really great, but most likely not the first thing you will implement (even though it is a very good enabler for resilience). More information on the Simian Army can be found on the Blog of Netflix. (https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116).Fix forward or roll back: these are the capabilities of your CI/CD pipeline, the heart of your automation efforts in DevOps. Your Continuous deployment should allow to roll back changes. Or do canary releases: for certain changes you don't go full park all the way, but deploy on a very limited set of servers/containers as a try-out and roll back if "the canary dies".ConclusionI could not find any explanation on the internet why SAFe® talks about SAFe® DevOps. The only thing I can think of is that they want to stress how DevOps culture, principles and practices seamlessly integrate with SAFe®. Similarly, SAFe® talks about SAFe® ScrumXP, where the good practices of Scrum and eXtreme Programming help to deliver good quality software every iteration and every program increment, not only on team level, but integrated with the other teams of the Agile Release Train.As far as the difference between CALMS and CALMR is concerned: they both cover the same ideas. In my humble opinion, the difference between CALMS and CALMR could be a matter of focus: maybe the initial focus of CALMS was to stress the importance of sharing knowledge, whereas the CALMR stresses more the need to be able to roll back a failing change.Bottomline, CALMS and CALMR may not be entirely equal, but they are definitely equivalent.Anyway:
Rated 4.0/5
based on 2 customer reviews
KnowledgeHut Editor
KnowledgeHut is a fast growing Management Consulting and Training firm that is a source of Intelligent Information support for businesses and professionals across the globe.
Posts by KnowledgeHut Editor
DevOps In 5 letters: Should We Say CALMS or CALMR?
By KnowledgeHut Editor
When someone asks me to explain what DevOps is about, I usually do this using the different letters of the acronym CALMS.CultureCulture is the foundation of DevOps. If you omit culture, you're only doing some symptoms of DevOps (like using a whiteboard, working in timeboxes and doing daily standup meetings won't make you an Agile team).Culture is about the people, about self-organized teams, about T-shaped profiles, about tearing down the wall between Development and Operations. A DevOps team takes end-to-end responsibility of an application or system: "you build it, you run it".If your organization has always been working in a command-and-control style, then the first thing to do is to instill a culture of team empowerment. And don’t underestimate this: this will probably take years to change.AutomationThis is where a lot of focus goes into and can be considered as the easiest to obtain. The heart of DevOps is the CI/CD pipeline: the continuous flow process that is triggered upon check-in of new versions of code. Continuous integration was already known in eXtreme Programming. In a DevOps context, the continuous delivery/deployment makes the story complete. To make your CI/CD pipeline work at its full capacity, you have to consider everything as code:Your source code of courseYour automated tests - unit tests, integration tests and so onYour configurationIncluding your infrastructure configurationYour database changesYour documentationBut automation is also about closing the feedback loop: getting observations, metrics from running system fed back into your team’s product backlog.Lean principlesDevOps is not about moving big chunks of changes to production, but instead, moving to a constant flow of small and easier to control changes. Flow, as in Kanban: limited work in progress, small batches. And moving to the production does not automatically mean: "going live". If there is a dependency with other code that is not yet ready, you can still disable your code via feature toggling until everything is ready to be activated.MeasuringThis is crucial to improving: define metrics on your process. How good are the things going in your organisation? Where is room for improvement? And the apply the typical Plan-Do-Check-Act/Adjust approach to gradually improve your way of working.SharingDevOps teams take full responsibility over their system. But this does not mean that they have to reinvent the wheel over and over again. They learn from their peers.Common senseThere are plenty of resources on the internet - blogs, pictures, slide decks and videos - that explain DevOps using this CALMS acronym. So by now, this acronym has become common sense for anyone who searched for some kind of definition of DevOps. Or hasn't it…?DevOps according to SAFe®, in 5 slightly different lettersRecently I had a discussion with a colleague who is a certified SAFe® Program Consultant and trainer. According to this colleague, SAFe® doesn’t talk about CALMS but about CALMR instead. She wanted to be sure we tell the same story and don’t confuse the people we train and coach. I am not going to give a full explanation of SAFe's definition of Devops, you can read it yourself on the SAFe® site (more specifically on this page www.scaledagileframework.com/devops).But I will briefly explain what the acronym CALMR stands for according to SAFe®:Culture of sharing responsibilityAutomation of continuous delivery pipelineLean flow accelerates deliveryMeasurement of everythingRecovery enables low-risk releasesThis discussion made me wonder: if a large part of the world talks about CALMS to define the principles of DevOps, then why does SAFe® talk about CALMR and what is the difference? And why do they call it "SAFe® DevOps"? So I did some investigation and this is what I found.What's the difference?In all honesty, whether you speak about CALMS or CALMR, in the end, both are equal, or better, equivalent. Let me explain why.In the CALMS acronym, the S stand for sharing. Sharing of knowledge, of experiences. Call it communities, or chapters and guilds if you are more into the way Spotify works. I deliberately don't call it "the Spotify model" because there is no Spotify Model (says Marcin Floryan, a Spotify chapter lead in this presentation: https://www.infoq.com/presentations/spotify-culture-stc).But that’s entirely different story.Sharing in CALMRIn "SAFe® DevOps", sharing is a part of the Culture. People work in teams. But teams together form a release train. So, these teams will not only need to align planning-wise, they also inspect and adapt during the IP sprint. And they learn continuously. OK, fair point. But sharing clearly is there in both definitions.Recovery in CALMSSo, what about the recovery aspect of SAFe® DevOps? Is it a part of the CALMS acronym too? In my opinion, yes, of course, divided over other aspects. The first thing that the SAFe® site tells about Recovery is "Stop the line mentality".Now, that is a Lean principle. Mary Poppendieck (Lean Software Development) mentions this in her presentations: "The greatest productivity comes from not tolerating defects. Create ways to detect defects the moment they occur” (see slide deck https://accu.org/content/conf2007/Poppendieck-Stop_the_Line_Quality.pdf ).The other parts, Plan for and rehearse failure and Build the environment and capability to fix forward and roll back, these are typically automation aspects. Plan for and rehearse failure talks about the chaos monkey.The Simian Army is a bunch of tools and concepts that will create chaos in your ecosystem: kill processes, slow down processing and so on. Chaos engineering is really great, but most likely not the first thing you will implement (even though it is a very good enabler for resilience). More information on the Simian Army can be found on the Blog of Netflix. (https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116).Fix forward or roll back: these are the capabilities of your CI/CD pipeline, the heart of your automation efforts in DevOps. Your Continuous deployment should allow to roll back changes. Or do canary releases: for certain changes you don't go full park all the way, but deploy on a very limited set of servers/containers as a try-out and roll back if "the canary dies".ConclusionI could not find any explanation on the internet why SAFe® talks about SAFe® DevOps. The only thing I can think of is that they want to stress how DevOps culture, principles and practices seamlessly integrate with SAFe®. Similarly, SAFe® talks about SAFe® ScrumXP, where the good practices of Scrum and eXtreme Programming help to deliver good quality software every iteration and every program increment, not only on team level, but integrated with the other teams of the Agile Release Train.As far as the difference between CALMS and CALMR is concerned: they both cover the same ideas. In my humble opinion, the difference between CALMS and CALMR could be a matter of focus: maybe the initial focus of CALMS was to stress the importance of sharing knowledge, whereas the CALMR stresses more the need to be able to roll back a failing change.Bottomline, CALMS and CALMR may not be entirely equal, but they are definitely equivalent.Anyway:
Rated 4.0/5
based on 2 customer reviews
190
- by KnowledgeHut Editor
- 07 Sep 2018
- 3 mins read
When someone asks me to explain what DevOps is abo... Read More
KnowledgeHut Celebrates 7 Years Of Continuous Learning And Knowledge Delivery
By KnowledgeHut Editor
In its perennial pursuit of optimized learning and spreading the power of knowledge across industries, KnowledgeHut has grown a year older. Stepping into its 7th anniversary, the organization, widely looked upon as a towering body of knowledge and skills has turned out to be a stable and powerful hub for the industry elites. From its humble beginning in Bangalore, India, the organization has grown over the past 7 years to become a beacon for customized coaching and consulting. Right from its infancy, KnowledgeHut has been on an unfailing mission to upskill tomorrow's workforce.The directors of KnowledgeHut, Mandarapu Nagaraju, Mallu Subramanyam Reddy, are proud to celebrate the company’s 7th year anniversary.Innovation is part of the company’s story. Supporting the clients, KnowledgeHut has always applied value-adding innovative ideas with updated methodologies. The productive team with full of professional drive, innovative ideas and creativity have worked endlessly this whole time to successfully achieve KnowledgeHut’s key objective- becoming the standard of excellence in the market.Words by our Co-founder and Managing Director- Subramanyam ReddySubramanyam Reddy (Co-founder and Managing Director of KnowledgeHut), shared some experiences and flashbacks from the history of KnowledgeHut. “The company was founded on July 19th, 2011 with just 10 staff members. The past seven years have been very successful. We had a clear vision for the organization and knew our goals and where we wanted to stand one day. We were always able to deliver at the highest quality and had the equipment and skills to overcome the issues and risks when faced and are very much exultant about our future as the organization to go miles ahead as a Global education provider.”The journey so farAchievements we are proud ofKnowledgeHut has been active in India for 7 years with its headquarters in Bangalore. More than 240 professionals are based in the Bangalore and Hyderabad offices working primarily over 250 professional training courses for the software management and development.Over these past 7 years, as we have certified over 1,20,000 professionals with unique learning opportunities, our global footprint has grown considerably. With more than 500 subject matter experts across 70 countries, KnowledgeHut now conducts classroom training, online training, and corporate training facilities that serve professionals everywhere.Here is a glimpse of what our students said about KnowledgeHut and how our courses have helped them flourish in their careers.It was not devoid of challengesWhile KnowledgeHut is currently undergoing a major organizational change since partnering with many accredited bodies, it is certainly worth mentioning how our efforts are going thus far. KnowledgeHut’s director, Mandarapu Nagaraju has reportedly been studying the way KnowledgeHut is organizing, both internally and externally, and made some major changes to how their training program works by analyzing all the things they are doing,.“Losses are part of trading, we learn something from them and move on. Definitely, there will be losses as long as there are risks. We believe that there will be no profits if the day ever comes when there are no risks at all” said Mandarapu Nagaraju.KnowledgeHut’s Vision for 2018Expand services and facilities into at least 100 countriesEnhance certification coursesContinue to focus on software trainingEnhance value-added servicesGrow business through staffing and recruiting platformCapital GrowthProfits are the key to a company’s success. They renew the capital and keep and attract the best people. It is our custom to share our profits with you all who helped in creating them as profitability is paramount to our future.Secrets to KnowledgeHut successIn the minds of people, delivering a consistent and uniform training is one of the most important secrets of the company success. The firm’s success has been laid solidly on three pillars: its leadership, its culture and its people.Great companies embrace great leaders who go on to secure a place in history. KnowledgeHut has been run by corps of extraordinary ability and vision. And while coming to competitors, clients, former employees, or partners, the conclusion is always the same i.e KnowledgeHut always recruits the highly talented people in the industry, seeking out the most ambitious and brightest employees who will fit into the province of its culture. That culture, widely replicated across the industry, has been the blueprint for the company’s success and has remained unique.KnowledgeHut LikelihoodsDuring the period 2018-2022, the global special education teacher training is poised to grow at a CAGR of around 3.77%.The global e-learning market is predicted to reach $325 billion by 2025 to reach approximately $325 billion USD.The fall in the training cost for employers is helping the corporate e-learning market develop consistently at a CAGR of around 11% by 2022.From the above statistics, it is predicted that KnowledgeHut might become the primary choice of all the major corporate clients for training and consulting services across the globe.Let’s celebrate this grand event togetherWe have reached yet another milestone in our journey of reinforcing your knowledge and skills on your professional career journey. And by ‘we’, we mean you and KnowledgeHut. It’s been 7 years and it’s time for us to celebrate together.On this event, the company has decided to offer some specials offers for you professionals and students. We are offering up to 10% cashback on all our courses. Avail the amazing offers before August 31, 2018, and become an expert in your dream field.Our discounts and couponsE-learning | Get 99% off on e-learning materials | Coupon Code: KHELEA7Seminar | Get 70% off on Live Conferences | KHCONF7Course | Get extra 7% off on all non-certification courses | KHCOUR7Webinar | Get free 7 months access to webinarsMeetups | Avail free meet-ups for 7 months (limited to India)Blog contribution | Participate in the contest and win rewardsSuccess story | Participate in the contest and win rewardsThe company truly appreciates the loyalty of the workforce and we are especially fortunate to have those personnel whose professional activity at KnowledgeHut lasted over 7 years. “Without the help of the best team, the best infrastructure, and the best SMEs, it is impossible to set up a successful training institute delivering services worldwide,” added Mallu Subramanyam Reddy.With astute business-mindedness and level-headed leadership running through its leadership team, KnowledgeHut’s success in the recent past is not surprising and is a force to reckon with in the race of training leadership worldwide especially in India and the US.
Rated 4.5/5
based on 2 customer reviews
590
- by KnowledgeHut Editor
- 21 Aug 2018
- 6 mins read
In its perennial pursuit of optimized learning and... Read More
A Definitive Guide To Understanding Essential Scrum Processes
By KnowledgeHut Editor
Introduction:There is no one who is working on software development or any related field and didn't hear about the Agile methodology and its benefits over the traditional software development like Waterfall method.Agile allows us to collect feedback about the product which we developed and its feature very early from the customer or management so we can make changes, defect repair or add a new feature to the product. Also, we always give the customer or management the most valuable features first before the less valuable features. These principles allow Agile teams to always introduce a valuable and shippable product. Agile has many frameworks that implement Agile principles but in different ways. The most popular among these frameworks are Scrum, XP, and Kanban.We will talk about the Scrum framework in many articles that will show its value, principles, and activities to facilitate it and give us some ways to implement all of these in real life.We will begin with these article as an introduction to Scrum and its main overview and benefits. So let’s begin. The State of Scrum report 2017-2018, it represents how Organizations are implementing Scrum within their company. Below is the diagramatic view of Scrum usage.What Is Scrum?As described in "Essential Scrum: A Practical Guide to the Most Popular Agile Process" book by Kenneth S. Rubin:Scrum is an Agile approach for developing innovative products and services. But when we want to implement Scrum, we can't depend on a definition, we must depend on specific steps. So let us show in a high-level description all the necessary steps (you should remember that this is an introduction to Scrum).We will show all of these in details in the next articles :Creating a Product Backlog: A prioritized list of the features and other capabilities needed to develop a successful product.Prioritize the backlog items, important or highest-priority items first.Begin with the feature that can be completed even it is low-priority than other features that we can’t complete within that sprint.Collect some items from the backlog by implementing conditions on steps 2 and 3 and put it on a time box called sprint. We must select items that are suitable to our Capacity of work in one sprint (we will talk in the next articles about sprint planning and velocity).The work is done in sprints that can be between 1 week and 4 weeks but the most popular is the 2-week sprint. In any sprint, we do all the work that allows us to produce a shippable product which is a product with completed and working features so we perform designing, development, testing and so on on the same sprint.At the end of the sprint, we conduct two activities: review meeting and retrospective meeting that we will describe below-a) Review meeting or a Demo:- In this meeting, we show our shippable product which has been ‘done’ in the sprint and collect feedback from stakeholders and perform any changes on existing feature or request for a new feature. Some books give a specific duration such as two hours on a two weeks’ sprint to these activities. But in my real life, some demos didn't take for my team more than 20 minutes.b) Retrospective meeting: The team discusses the work of the sprint and what went right so they can use it in the upcoming sprints. They also discuss ‘what went wrong’ so they can avoid it and think of ‘what can be done’ to improve work and cooperation between the team. It also can be short and you shouldn't make it more than half an hour even though a lot of books say it can also be about two hours on a two weeks’ sprint.Scrum benefits :As what was mentioned by Kenneth S. Rubin in his book "Essential Scrum: A Practical Guide to the Most Popular Agile Process", there are a lot of benefits coming from using Scrum in our work. Some of them are:1-Delight Customers: At the beginning of any product lifecycle, the requirements are not clear enough and sometimes there are a lot of requirements that the customer himself does not know well at this early time. So by using Scrum, we always show the customer a working product and collect his feedback. So in the end, we find that all requirements of customer are met in the final product.2-Improve Return on Investment:We don't have to wait till the end of product development to gain a return on investment. We gain a return on investment with every release3-Reduce Costs :We can reduce costs by eliminating the waste and dysfunction steps.4-Fast Results:The scrum sprint is short between 1 week and 4 weeks as often. At the end of each sprint, we deliver working, integrated, tested, business-valuable features. So the result comes very fast. 5- Confidence to succeed in a complex world :In the real world, we deal with many parties such as competitors, customers, users, regulatory bodies, and other stakeholders and we always must take quick and suitable actions as changing some requirements, adding some new features, using some new technologies or improving the quality standards to achieve stakeholders’ satisfaction and to provide a competitive product. 6- More Joy :The teamwork does not have to wait till the end of the product development to make a change in some features. They always gain feedback and always make corrective actions. These automatically bring more joy to work. The below figure shows the Scrum benefits.We now know what is the Scrum framework, what is the difference between Scrum and the traditional software methodologies and what is the benefit of using Scrum. In the next article, we will look in depth at the Scrum team and roles and then we will look in-depth in each specific area in scrum principles and implementation.
Rated 4.0/5
based on 1 customer reviews
293
- by KnowledgeHut Editor
- 03 Aug 2018
- 3 mins read
Introduction:There is no one who is working on sof... Read More
INFOGRAPHIC : The Power of Planning and Estimating in Agile
By KnowledgeHut Editor
Estimating and planning is an important aspect of the Agile methodology. Every plan will help in building a platform to develop a project and estimation will help in filling the gap and remove the hindrances in the software development process. The Agile Methodology roughly provides an idea of how a project manager can plan and estimate to make project success. Estimating and planning are the two factors which influence the outcome of any project.Agile planning is all about measuring the speed at which a team can turn user stories into functional production-ready software. Estimating and planning are critical for the success of a software development project. It may involve various challenges due to estimation done by the wrong person which leads to mismatch in the process. It is a waste, if a team works without any specific requirement, and moreover if the tasks are not assigned properly, it may result in excess time and efforts.Agile planning bears a great significance when compared to Non-Agile planning.The step-by-step actions are taken through the user stories, whereas in case of Non-Agile planning, the focus is more on the problem. Often a question arises as to how one should implement Scrum for a large-scaled software development. It can be through 5 levels of Agile planning because they render flexibility on how you and the organization want to implement planning, based on teams, environment, and culture. The planning levels start with product vision which includes product owner taking care of the entire product right from the beginning with respect to the product structure as well. Product roadmap planning, which focuses on implementing the product involves product manager and the product owner. The next step is release planning where the project manager and his team involves and delivers the releasable product.Coming to Iteration Planning, it is basically an event where all team members determine how much of the team backlog they can commit to deliver during an upcoming Iteration and the entire work slots are determined. The team summarizes the work as a set of committed iteration goals. The end stage is the daily commitment planning where the team discusses the progress of the project and updates are given.Agile planning life cycle includes involvement of stakeholders, updating the status of the project and checking through what has to be improved for the further action and later improvements through Build-Measure-Learn cycle.The last phase deals with the Estimation step wherein the project expert’s opinions are taken into consideration for the development of the project growth, and breaking the bigger tasks into smaller units which helps in understanding the requirements better. Later, estimation is done through Retrospectives. This involves looking back at events that took place, or works that were produced, and at the end delivers a high quality software.Planning and Estimation is hard, estimates can be made as accurate as possible through a proper collaboration with the Product Owner.In summary, Agile estimation is a team sport where the team members-Estimate smarter not harderLearn from past experience.Only a right planning and estimation delivers the best product.
Rated 4.0/5
based on 2 customer reviews
291
- by KnowledgeHut Editor
- 11 Jul 2018
Estimating and planning is an important aspect of ... Read More
Are You Writing The Best User Stories In Agile?
By KnowledgeHut Editor
WHAT IS A USER STORY?A user story is a part of an Agile software development approach to present the details of a requirement from a customer’s point of view. A user story specifies what type of user you are, what you want and the reason behind it. A user story helps to create a simple and short description of a requirement told from the user’s perspective.They generally follow a simple approach for a user story:As a < type of user >, I want < a goal > so that < a reason >.Another approach includes:As a , I want because .Originally, Agile user stories were meant to be very short and simple to write on sticky notes or index cards. They were fixed on tables or walls to simplify their planning and discussions. Therefore, they actively shift the target from writing about features to explaining them. In reality, these explanations are more important than the story is written. We can know them prominently in any major Agile process.What does a user story mean? Let us try to understand with an example.Imagine you are using an app on your phone. Now, you like the app, but you would love to have an additional feature in this app. How would you describe your wish to the developer of the app? You will say something like-"I want to have X functionality so that I am able to get Y benefit."While creating a user story, you write in the exact same way, the only additional information which you need to provide is about the type of user you are.The advantages of user stories can be written at different levels in details. We can write a user story to cover a huge amount of functionalities. These large user stories are generally called ‘epics’. Let us clarify this with a few more examples-“As a user, I can view the license terms before purchasing or subscribing so that I know what I’m getting.”“As an app user, I can read FAQs, so I can get quick answers.”“As a website admin, I want all the offers to get unpublished on the website after 7 days of publishing so that the expired offers are not still listed if I forget to delete them.”In all these examples, it is clear who want the features, what they want, and what benefits they would get with the additional functionality.WHO WRITES THE USER STORIES?Business people are responsible for writing the user stories in a customer-specific language. We have to do this because we want user requirements to be clean and clear to both the development team and the business. The role of a development team is to satisfy the end-user acceptance criteria of the storyboard. In Scrum process, the product owner is responsible to represent the business as well as to finish the activity.WHEN TO WRITE USER STORIES?In an Agile project, User stories are generally written in the end. Usually, writing a user story workshop is held close to the beginning of the project in Agile. Everyone should participate in writing or adding the user stories to the product backlog at any time. If your team members are predicted to deliver the stories, then roughly we have to maintain 3 sprints of user stories in the backlog. The additional aspects of efforts and features are a superset of user stories. In these cases, the product owner team interacts with the development team to split user stories into enough levels.WHY ARE USER STORIES USED IN SOFTWARE DEVELOPMENT?User stories are used because they provide many benefits in software development. Here are some of them.User stories help in delivering value to the customer.User stories talk about the immediate customer needs. Because of this, the features implemented and delivered to the end user is of the highest value.User stories enable a project to be quickly adjustable.Since user stories help in adding small features one by one, it becomes easier for the developing team to steer towards new direction if it is required.User stories increase the collaboration of end user.Since user stories are short, the people involved in the project need more explanation from the end user to clearly understand the story. This increases user collaboration.User stories are followed by Acceptance Criteria. Acceptance Criteria clarifies the end user that in which situations the story will be fulfilled. They are a list of requirements. They are written in "Given, When, Then" format.Let us see an example for a clearer understanding of user stories. Suppose, there is a story for a website user which goes like this-"As a logged out user,I want to be able to sign in to the website,So that I can see my previous transactions."Now the acceptance criteria for this story can go something like thisScenario: The registered user signs in with a valid username and password“Given I am logged out of the websiteand I am on the Sign-In page.When I fill in the “Username” and “Password” fields with my valid credentialsand I click the Sign-In buttonThen I get signed in to the website”Acceptance criteria help in creating a clear understanding between the developers and the clients about when and how the features will work. The client understands what to expect from the project. And hence, the chances of miscommunication between the parties get reduced.
Rated 3.5/5
based on 4 customer reviews
254
- by KnowledgeHut Editor
- 04 Jul 2018
- 3 mins read
WHAT IS A USER STORY?A user story is a part of an ... Read More
Key Process Groups In Project Integration Management
By KnowledgeHut Editor
What is Project Integration Management?As per Project Management Institute (PMIⓇ), Project Integration Management is the first project management knowledge area, which mainly pertains to the procedures required to guarantee that the different tasks of the project are co-ordinated appropriately.While developing a project, the entire sub-processes are integrated to form a whole project, and that constitutes the concept called ‘project handling’. Project Integration Management consists of the 6 project integration management processes like Initiation, Planning, Execution, project monitoring and control and closing a project. We will see the importance of project integration management processes in details. Importance of project integration managementThe motive behind implementing a project integration management is as follows:Managing and coordinating all the tasks with processes to develop a whole project during a project life-cycleConducting a whole project in order to produce an outcome systematically as each process in the project integration management has some purpose to achieve the main project goal.As per the PMBOK® 4th edition, the processes involved in the project integration knowledge areas and steps for implementing project integration management are as follows:6 Project Integration Management processesProcess 1: Developing a Project CharterThe project charter plays a pivotal role in Project Integration Management. A project can’t start leaving this process. This process belongs to the Project Initiation phase. It defines the objectives of the project to produce a project charter. The high-level project information includes a name, description and what will be the end product. The project charter helps in authorizing the project in the enterprise to begin the next process.The table below shows the inputs, project integration management tools and techniques, and outputs of the project charter process.A project charter is a key resource of the project information. The project charter anchors the project and should include the following:Mentioning the project title and descriptionStating the business requirements and business caseListing the project targetsDefining the risksIdentifying the resources of the project and technologies neededListing the end productIdentifying the project managers and team members and adding their roles and responsibilitiesDelineating the budgetProcess 2: Developing a project planThe project plan development is the second step in project integration management. It comes under the Planning phase. It takes the output of the other planning processes to create a continuous and logical document that can be used during project execution. This process includes appropriate project planning and generating various project management plans like scope management, cost management, time management plans etc. The project plan directs the execution of the project, documenting various planning assumptions, communicating with the clients etc. The table below shows the inputs, project integration management tools and techniques, and outputs of the project planning process.The document consists of all the project requirements to meet the end product and deadlines. The statement should include the following:Project objectivesGoalsTasksStakeholdersProject requirements listResourcesBudgetScheduleChange request processCommunication methodologiesProcess 3: Directing and Managing a project workThis is the third process in project integration management and belongs to the Execution area. In this process, the tasks are carried out as described in the project management plan and changes are made according to the project needs. During this phase, the project outcomes are generated and delivered to the stakeholders. This step mainly focuses on delivering the end product to the customers. The table below shows the inputs, project integration management tools and techniques, and outputs of the Execution process. Process 4: Monitoring and controlling a project work This is the fourth phase in project integration management. It belongs to the Project Monitoring phase. User requirements are gathered, plans are made ready and the execution starts. Still, it is not guaranteed to get the actual results as you planned, regardless of whether it is a good plan. Variations from the planned things are measured with the help of monitor and control project work process. Also, this phase includes tracing, cross-verifying, and revealing the progress in order to meet the objectives of the project management plan. The table below shows the inputs, project integration management tools and techniques, and outputs of the Monitor and Control process.Process 5: Performing Integrated Change controlThis is the fifth process in project integration management which belongs to the Project Monitoring and Control process group. You may need to do changes, due to the variations in the planned values or the customer may ask you to do some changes to the project.E.g. The customers might ask for a new requirement or they might require changes in the existing product. Such change requests are evaluated by the Change control phase by finding out the alternative solutions and its impact on the project. Perform Integrated change control phase ensures the appropriate implementation of the required changes in the project.The table below shows the inputs, project integration management tools and techniques, and outputs of the Performing Integrated Change control process.Process 6: Close Phase Close phase is the last step while implementing project integration management belongs to the Project Closing process group. Once the project is finished, this process indicates the formal completion of the project. If all the project objectives are met and the customer agrees to the final product, then that project or phase (phase belongs to a large project) can be closed declaring the project to be completed officially. The table below shows the inputs, project integration management tools and techniques, and outputs of the Close process.Coming to the Conclusion As stated above in the project integration management tutorial, we have studied all the key process groups in project integration management. Also, we have seen that all the projects require a concrete project plan to finally have the desired end product. It is up to the project manager and the project team to create one. Then the project manager must work with the project team to ensure the work is being completed as it was planned. The project manager must follow all the subsidiary project plans, such as the Risk Management Plan, the Schedule Management Plan, and the Communications Plan. Finally, the project manager must work throughout the project to control changes across all the facets of the project.There are the sure-fire ways to succeed through the PMPⓇ Certification training. The training will help Project Managers address these processes and other complex points of interest that are aligned with the same. With the right certifications, you can familiarize yourself with the project management related terminologies, learn ways to gain success in the project and know what works well and what not while implementing a project plan.
Rated 4.0/5
based on 5 customer reviews
194
- by KnowledgeHut Editor
- 20 Jun 2018
- 1 mins read
What is Project Integration Management?As per Proj... Read More