Search

Themes, Epics, And The Art Of Writing User Stories

User stories are as critical and essential in the Scrum world as the requirement documents in the traditional Waterfall world. Even if we try to avoid the controversial comparison, the need for both is unavoidable.Please note, the Scrum Guide doesn’t talk about the user stories. So, the very definition, scope or constraints of user stories are open to interpretation and the subject to be improvised.Though the widely popular and acceptable understanding of user stories is that-The user stories are the requirements told from end-user perspective to capture the description of a product feature.So, what are epics and themes?An epic is a large story which is comprised of potential smaller stories for implementation. The stories in an epic have a common objective. And thus, it often makes more sense to deliver all user stories of a single epic at one go.Theme is even a bigger brother of both epics and user stories. The focus area of a theme is generally of an organization level.A follow-up question may be –Why don’t we document all requirements just as stories?The answer is – the size. It is difficult to document organization-level requirements as stories. And it is also difficult to implement requirements that are as big as epics. Thus the requirement capture goes as-Themes -> Epics -> Stories.While the implementation adds up as-Stories -> Epics -> Themes.Writing the user stories is what we are going to focus more in this article. ‘Why’ we need user stories, I am assuming is obvious to many. The ‘how’ part is what we will talk about now.User stories can be horizontal slicing of product features or vertical.Horizontal slicing is breaking down the stories by the type (/component/technologies) of work. While vertical slicing is breaking down the stories by the business features. So, if we are making a shopping portal, the horizontal slices are stories based on backend, integration, UI, or testing functionalities. While, vertical slicing would be driven by business features like login, checkout, payment etc.Let’s take the analogy of cutting a birthday cake. Horizontally cutting will give you either the base cake or frosting or fondant decoration. While a vertical slice will be everything, but of an eatable size.Horizontal breakdown is a never a good idea with Scrum (nor while cutting a birthday cake). The reasons being:It doesn’t fit well with the definition of done. Even if you have delivered a backend story or a UI story, it is not a testable, working or deployable feature.There are interdependencies among the pieces as they can be tested only they after they are stitched together.Let us take the scenario of an online shop to sell art supplies. We will have standard business features like-LoginRegistration of usersAdding items into shopping cartPaymentLogoutSo if we write –“As a user, I should be able to check out the items I have added in my cart”, this is not granular enough to implement. This is our ‘epic’.Our user stories can be:“As a first time user, I will be asked to either register or purchase as a guest user when I check out the items I have added in my cart”“As a registered user, I will be shown the items added in my wish list so that if I want I can add them to my cart when I check out”If you feel the stories are still vague, the user stories can be made more detailed by adding “conditions of satisfaction”. And if needed, they can be split into multiple, smaller user stories.Additional considerations for writing good user stories:1) SizeSince the Scrum Guide doesn’t talk about user stories, there is no standard rule of how big (or small) a user story is meant to be. By all practical purposes we know – it has to be small enough to be delivered as a part of one sprint. With the better understanding of Scrum and team dynamics, the team gets better at estimating the size of a user story or how many stories they can accommodate in a sprint.2) PerspectiveUser stories are always written from the perspective of an end user (or customer).  So the widely used template is –As a < (specific) type of user >, I want < goal/business feature > so that < reason to validate the goal/business feature >.3) AuthorIt is the product owner’s responsibility to ensure the product backlog of Agile user stories exists. However, it is of not much importance who actually are writing those stories. In a happy scenario, all team members should be capable enough to write user stories.4) SimplicityLike any English statement; a simple, readable and easily understandable statement is the want of one and all. The best stories are the ones that leave no scope of ambiguity. Write your stories so that they are easy to understand. Keep them simple and concise. Please note – user stories should include the format- who-wants what-why.The ‘how’ shouldn’t be included. ‘How’ is the technical implementation part, better left to the teams to decide.5) ReadinessThe user stories have to be granular enough to be taken up by the team to implement. One has to keep refining the stories until they are ‘ready’ (to be implemented). Break down the epics, to the more implementable size stories. Another aspect of readiness is that team is having a shared common understanding of the user stories of the current sprint.6) AccessibilityKeep your stories visible and accessible to the team. The product backlog is an evolving artifact and explains the product vision. The team needs to be aligned with the product vision. Thus the access to product backlog and the user stories helps the team with the implementation and sprint planning. One quick way is to put up the user stories of the current sprint on a wall. Sticky notes, posters, paper cards, whatever works with the team. This fosters collaboration and creates transparency.7) Beyond StoriesSo far we talked about what are user stories, how to break them down, and the tips and tricks to write better stories. Yet in the end, I am asking you not to rely completely on user stories.The reason is simple.A great product needs more than stories. User story is a great tool to capture business features or product functionality, but they cannot help much with user journeys. An assisted visual journey using story maps, sketches, mock-ups, workflow diagrams helps the team further to understand the overall flow.
Themes, Epics, And The Art Of Writing User Stories
Amrita
Rated 4.0/5 based on 4 customer reviews

Themes, Epics, And The Art Of Writing User Stories

User stories are as critical and essential in the Scrum world as the requirement documents in the traditional Waterfall world. Even if we try to avoid the controversial comparison, the need for both is unavoidable.Please note, the Scrum Guide doesn’t talk about the user stories. So, the very definition, scope or constraints of user stories are open to interpretation and the subject to be improvised.Though the widely popular and acceptable understanding of user stories is that-The user stories are the requirements told from end-user perspective to capture the description of a product feature.So, what are epics and themes?An epic is a large story which is comprised of potential smaller stories for implementation. The stories in an epic have a common objective. And thus, it often makes more sense to deliver all user stories of a single epic at one go.Theme is even a bigger brother of both epics and user stories. The focus area of a theme is generally of an organization level.A follow-up question may be –Why don’t we document all requirements just as stories?The answer is – the size. It is difficult to document organization-level requirements as stories. And it is also difficult to implement requirements that are as big as epics. Thus the requirement capture goes as-Themes -> Epics -> Stories.While the implementation adds up as-Stories -> Epics -> Themes.Writing the user stories is what we are going to focus more in this article. ‘Why’ we need user stories, I am assuming is obvious to many. The ‘how’ part is what we will talk about now.User stories can be horizontal slicing of product features or vertical.Horizontal slicing is breaking down the stories by the type (/component/technologies) of work. While vertical slicing is breaking down the stories by the business features. So, if we are making a shopping portal, the horizontal slices are stories based on backend, integration, UI, or testing functionalities. While, vertical slicing would be driven by business features like login, checkout, payment etc.Let’s take the analogy of cutting a birthday cake. Horizontally cutting will give you either the base cake or frosting or fondant decoration. While a vertical slice will be everything, but of an eatable size.Horizontal breakdown is a never a good idea with Scrum (nor while cutting a birthday cake). The reasons being:It doesn’t fit well with the definition of done. Even if you have delivered a backend story or a UI story, it is not a testable, working or deployable feature.There are interdependencies among the pieces as they can be tested only they after they are stitched together.Let us take the scenario of an online shop to sell art supplies. We will have standard business features like-LoginRegistration of usersAdding items into shopping cartPaymentLogoutSo if we write –“As a user, I should be able to check out the items I have added in my cart”, this is not granular enough to implement. This is our ‘epic’.Our user stories can be:“As a first time user, I will be asked to either register or purchase as a guest user when I check out the items I have added in my cart”“As a registered user, I will be shown the items added in my wish list so that if I want I can add them to my cart when I check out”If you feel the stories are still vague, the user stories can be made more detailed by adding “conditions of satisfaction”. And if needed, they can be split into multiple, smaller user stories.Additional considerations for writing good user stories:1) SizeSince the Scrum Guide doesn’t talk about user stories, there is no standard rule of how big (or small) a user story is meant to be. By all practical purposes we know – it has to be small enough to be delivered as a part of one sprint. With the better understanding of Scrum and team dynamics, the team gets better at estimating the size of a user story or how many stories they can accommodate in a sprint.2) PerspectiveUser stories are always written from the perspective of an end user (or customer).  So the widely used template is –As a < (specific) type of user >, I want < goal/business feature > so that < reason to validate the goal/business feature >.3) AuthorIt is the product owner’s responsibility to ensure the product backlog of Agile user stories exists. However, it is of not much importance who actually are writing those stories. In a happy scenario, all team members should be capable enough to write user stories.4) SimplicityLike any English statement; a simple, readable and easily understandable statement is the want of one and all. The best stories are the ones that leave no scope of ambiguity. Write your stories so that they are easy to understand. Keep them simple and concise. Please note – user stories should include the format- who-wants what-why.The ‘how’ shouldn’t be included. ‘How’ is the technical implementation part, better left to the teams to decide.5) ReadinessThe user stories have to be granular enough to be taken up by the team to implement. One has to keep refining the stories until they are ‘ready’ (to be implemented). Break down the epics, to the more implementable size stories. Another aspect of readiness is that team is having a shared common understanding of the user stories of the current sprint.6) AccessibilityKeep your stories visible and accessible to the team. The product backlog is an evolving artifact and explains the product vision. The team needs to be aligned with the product vision. Thus the access to product backlog and the user stories helps the team with the implementation and sprint planning. One quick way is to put up the user stories of the current sprint on a wall. Sticky notes, posters, paper cards, whatever works with the team. This fosters collaboration and creates transparency.7) Beyond StoriesSo far we talked about what are user stories, how to break them down, and the tips and tricks to write better stories. Yet in the end, I am asking you not to rely completely on user stories.The reason is simple.A great product needs more than stories. User story is a great tool to capture business features or product functionality, but they cannot help much with user journeys. An assisted visual journey using story maps, sketches, mock-ups, workflow diagrams helps the team further to understand the overall flow.
Rated 4.0/5 based on 4 customer reviews
Themes, Epics, And The Art Of Writing User Stories

User stories are as critical and essential in the Scrum world as the r... Read More

3 Red Flags Agile Facilitators Should Watch Out For & The Best Solutions

90% of executives believe that organizational agility is critical to business success.Agile working methods are more successful than traditional methods (71.5% and 62.8% respectively).So why hasn’t working Agile yet become the norm? That’s not to say it hasn’t become a trend, and I’m sure you’ve begun seeing it - as I have - referred to in business settings across industries.Most often it is down to not knowing where to begin, not having a team fully on-board or being unable to deliver proven success soon enough. Starting out on an Agile project with little confidence, only a general knowledge of the method and a ‘succeed first or scrap it’ mentality from the business can lead teams to run-ins with common pitfalls.Let’s shed some light on  what I believe are three of the most common and impactful pitfalls on a business's first run at Agile on a small scale (i.e. “Innovation Engine” separated from the “Performance Engine” (explore this topic), instead of immediate enterprise-scale Agile transformation).We won’t only focus on the negative. I’ll share what we as a team discovered are the best ways to overcome or to prevent these obstacles altogether.Minimizing the risk of failure before embarking on an Agile adventure is the key.1) Lack of top-level supportThis seems obvious I know, but it’s good to be aware that even the management who has given the go-ahead can be unsupportive of the Agile project. On one hand, they may not act on what they promised, for example, giving teams the real freedom to innovate and take time away from usual tasks within the company, or actually implementing project outcomes and taking it seriously. On the other hand, they may not defend the project to other management-level staff and decision makers.Either way, this behavior can seriously impede the overall success of working Agile.Striking a balance can be tough.Too much input and encouragement from top-level management can make Agile projects feel imposed. On the other hand, teams can feel empowered by management support.For the best chance of getting it right, our first step is to make sure clients we work with are genuinely interested and excited by the prospect and potential of Agile, and also fully understand the limitations and possibilities within their own company setting.Are you receiving a complete support from the management?We always go into a project knowing we have the full support of key decision makers and leaders. Whether the management shows a genuine interest, or just a general interest but seem overly cautious, we always start a kickoff with a content input pack to give a short but comprehensive overview of Agile, its principles, and its process.When we have the support, we aim to get the team together who will be involved in the project - sans manager - to allow them to be open with their questions and apprehension before really getting started with the project.Transition to the next level(s)- Is your team ready?Getting employees on the team level excited about Agile is part two. Knowing they have the full support of management, but also trusted with the freedom to execute the project themselves and are able to see the effects of project outcomes on the wider company are all crucial components to maintaining an energetic, motivated, and happy Agile team.We do also start out with a workshop including Agile simulations as the core activities where we aim to include managers or at least the responsible sponsor of the project. This initial workshop aims to bring everyone to the same level of understanding about how the project will work - the timings and how everyone can work with one another for the most successful outcome.2) Team members with strong identities with traditional rolesI must make a distinction between those who strongly identify with their roles, and strong personalities. Strong personalities (in most cases) can be harnessed and encouraged to work effectively within the Agile team by an experienced facilitator. Those who strongly identify with their role - meaning their role within the company, not within the Agile team - can be more difficult to sway to an Agile way of thinking.In the dynamic setup of an Agile project, team members need to be prepared to consistently step out of their comfort zones, to multi-task and to learn their co-workers’ jobs, or at least their point of view, and have the open-mindedness and approach to do so with empathy and without contempt.Mindset > SkillsOften, just the action of taking responsibility for getting something done for a deadline set in the project, even if it isn’t an employee's usual job is enough to bring them into the mindset of working flexibly and collaboratively. Sometimes it takes a little more encouragement.Something we found to be very important for an Agile team - especially on their first project - is to make sure they have a separate working environment. This keeps them focused on the Agile team-specific goal, and away from the traditional, waterfall environment within which their usual role is so fixed.Keeping the Agile team small also helps with bringing a team closer. Smaller teams within the Agile team don’t have a chance to form as a result of people being drawn to those they usually work with. Hence we suggest one representative from each department is present.By also truly understanding the Agile mindset as a result of studying the core values and principles, team members can see the value of having mutual respect for others. It can help them realize how much they could learn from their new teammates, and the potential a cooperative team can have when it comes to the project outcome.An example of a team stepping away from their traditional roles to get results and reach their goals happened recently with a team I worked with. Some user research was needed, and usually, this consisted of reaching out to the research team who put together a questionnaire, potentially over days or a week. The interviews then need to be set up and the sales team gets involved to make decisions on incentives and resources. Another department then is needed to carry out the interviews.In this Agile way of working, this one team is self-organized. They do it all, and any member of the team can carry out the tasks. The work is evenly shared for the absolute quickest output so the team can continue forward towards their joint goal.Without a fully committed and cooperative team, this is just not possible.3) Tools unfit for efficient information-sharingAgile is about working quickly, working efficiently, and that getting things done is more important than having things perfect. Continuous face-to-face interaction aims to ensure this happens to avoid any misunderstanding, miscommunication and to ensure deadlines are met.As much of Agile projects today are focused on something intangible, i.e. software, UX designs or CX journeys, the right tool to support this ongoing interaction and updating of tasks needs to accompany the team throughout the project.Selecting the right tool from day one is crucial. It keeps people’s minds on the important things, and off the time-consuming admin.Discard useless tools!There’s no room in an Agile team for tools that impede progress by demanding too much attention from one or more team members, by confusing people or simply failing by losing data.We keep a small, selective collection of tools we have found work best for this kind of project-based, live collaboration. Teams are then able to choose, perhaps depending on which they’re most familiar with to make the onboarding faster and easier (these include Slack and G-Suite, we have also heard Atlassian are extending their project management software to enterprises working Agile, but have yet to try it out).Keeping an eye open for these red flags could save teams time and resources, not to mention the invaluable confidence in Agile working an initial successful project could instil in them.Ultimately it’s about finding how each team works best with one another to really get the most out of an Agile project - these tips simply help them focus on this, and not on roadblocks.
Rated 4.0/5 based on 5 customer reviews
3 Red Flags Agile Facilitators Should Watch Out Fo...

90% of executives believe that organizational agility is critical to b... Read More

INFOGRAPHIC : The Power of Planning and Estimating in Agile

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
INFOGRAPHIC : The Power of Planning and Estimating...

Estimating and planning is an important aspect of the Agile methodolog... Read More

Are You Writing The Best User Stories In Agile?

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
Are You Writing The Best User Stories In Agile?

WHAT IS A USER STORY?A user story is a part of an Agile software devel... Read More

Make Your Agile ‘WAIT’ Visible & Worthwhile

Waiting for something or someone is one of the most annoying things in life. I’m sure all of you have faced such situation in a real life. How about waiting nervously till your examination results arrive? How about waiting for your fiancé or fiancée to come and meet you? And how about waiting till you get your increment or promotion? Strenuous and frustrating isn’t it? It just eats you away minute-by-minute, day-by-day fretting away at what might just be a risky unknown.Well, waiting is a common thing. May it be personal life or even when executing software development projects. This is no difference even in a change-driven Agile project. In Agile terms, waiting is the result of an impediment of any shape or form.So what is an impediment?The dictionary definition of an impediment is ‘a hindrance or an obstruction to doing something’. In Agile terms, an impediment is ‘anything that is slowing down the team’. In PMP terms an impediment is ‘any kind of issue’. An impediment simply makes an Agile team wait!!So, what can make an Agile team wait?An Agile team may end up waiting forInformationResources; human or non-humanAnother task or a featureAdviceFeedbackTools or TechnologyManagement decisions, or lack of itWork environment itselfAbove are just some reasons while a team may get blocked from achieving their objectives. It will stop them from getting things ‘Done’ which finally affects their velocity.So what should you do with the thing that makes you wait? Let’s take a look at it next!!Making the ‘wait’ visibleA core concept in Agile is to make everything transparent and visible. We achieve this mainly by showing things in the information radiator (or our scrum board) or by discussing things during the scrum ceremonies. Here are a few things that you can do to make the ‘wait’ visible.Add a ‘waiting’ column to your scrum board – Move the tasks or user stories that are blocked to a swimlane named ‘waiting’ and make it visible for everyone as soon as you identify it. Don’t wait!!The swimlane alone does not suffice. Add some more notes (in coloured sticky notes or cards) with information such as why it is blocked, who are you waiting for, what are you waiting for, when do you expect a resolution, how the impediment will be removed, and what is the impact etc.Notify the relevant stakeholders about the impediment – Your scrum master is your ‘Protector’. Make him aware of all your impediments as soon as you identify it. Bring it up during the immediate daily scrum meeting so that the scrum master can identify a way forward and facilitate a process to resolve the impedimentMaking the ‘wait’ worthwhileIt’s all good to identify and highlight impediments as explained above. Action or steps to find solutions for these impediments will take some time. In software development, a minute wasted may result in delays in project timelines that may have detrimental consequences on time, cost, and scope. So, how can you make the wait worthwhile?The team members blocked must make maximum use out of the waiting time. Below are some of the paths that he or she can tread while ‘waiting’.Add more information as to why you are waiting. Information and collaboration is the key to resolving issues. The more guidance and information that can be provided on the issue itself will make it easier for the assignee to resolve that blocker.Move on to another task – If there is nothing else to do on the item blocked then just move on and keep the flow of other tasks going. Agile stresses on the progress of stories and tasks in a sprint on a daily basis and you will achieve this only by working on the other tasks.Help others or get help – Don’t be shy!! Collaboration and communication is the key in Agile. Work with team members to either solve the issue or help them resolve the blocker.Research on the root cause of the blocker or on a resolution for the impediment. Agile teams need to be innovative and this is the best way of making use of ‘waiting time’ judiciouslyThe following video will give you a clear picture of the impediments encountered by Agile and Scrum teams.ConclusionImpediments and wait is an inevitable thing in Agile projects. It is up to the team members to identify the best way to identify, record, manage, update and resolve impediments. Agile principles and values provides guidance on what needs to happen but it is up to the team to ascertain what works well for the team while ‘waiting’.So, happy waiting to you!!
Rated 4.5/5 based on 3 customer reviews
Make Your Agile ‘WAIT’ Visible & Worthwhile

Waiting for something or someone is one of the most annoying things in... Read More

The Added Value of Agile and Project Management Certifications

Over the years, I've heard so many different opinions and read so many articles about what people think of certifications. Some do not see any added value while others believe otherwise.Let us think about getting certified from an Agile Mindset:Agile Team: The candidate is the Customer (Product Owner), Scrum Master & Development Team all in one.Value Maximizing: The market is getting more competitive, new technologies are emerging and will soon be dominant over traditional methods so the candidate has to inspect what value can they add to their experience / knowledge to cope with all those changes and competitiveness and then adapt accordingly.Release Planning / GoalPlan & Prioritize your Backlog (Define User Stories like Taking a Course, Complete Application, Apply & Book for the exam)Set the release goal: “As a Project Management Professional, I want to Obtain X-Certification in order to gain more knowledge in Y-Industry”Estimate the time & cost. Iteration Planning / Goal: Decompose the User Stories into tasks (If necessary) and set a goal for each iteration. For example, for the first iteration: Iteration Goal: Complete a Course within 2 weeks.Iteration Tasks: Find a Course, Register & Pay, Take Course.While doing different iterations, you inspect and adapt to ensure you are on the right path by frequently reviewing your progress, checking if any improvement is needed for your study approach or plan and so on until you reach your last iteration:Iteration Goal: Pass the TestIteration Tasks: Register & Pay, Find a date, Sit for the test.Going through this whole process of inspection and adaptation frequently will help professionals assess four important How’s:How competitive is the market?  How familiar are they with all emerging technologies?  How can they improve?How will this improvement add value to their career ?Certifications are not about adding letters after your name but it is about knowledge and personal/ professional development. So if you have the experience and knowledge, what is stopping you from getting certified. Certifications will:Add to your knowledge in many ways.Pave the way for your for a more distinguished career path.Make you stand out in competitive & tight job markets.Validate your Experience.Help you speak a common language among professionals of the same field.Project Management is one of the most competitive jobs worldwide so do not aim at reaching the top and stop because what is more important than reaching the top is staying there.In light of the above, I would like to share how different certifications/designations added value to my Professional Development & Career: (Inspection & Adaption over the years) Project Management Professional (PMP)No matter how many years of experience we have, there is always more to learn so getting my PMP helped me get in-depth knowledge of all project management processes, tool and techniques in addition to opening my eyes on how to better manage some critical Knowledge Areas / Processes, especially Effective & Efficient Communication & Stakeholder Engagement.Risk Management Professional (PMI-RMP)After several years working in the Project Management field and performing different levels of Risk Analysis on almost every project, you will be surprised to hear that getting this certification opened my eyes to so many aspects of the Risk Management and made me realize that there are certain things I can do in a different and better way.Scheduling Professional (PMI-SP)Having more than 10 Years of experience in Estimating, Scheduling & Planning, going through the SP Journey did reinforce this knowledge & experience with a certification from a highly reputable organization like PMI.Green Project Manager (GPM-b)Many countries are adopting green and sustainability initiatives to protect the environment and the world as a whole. Being in the Real Estate Development Industry, I worked for many years on some sustainability initiatives on many projects. Getting the GPM-b reinforced my knowledge about sustainability and how to apply it in Project Management which enhanced my approach on how to incorporate those initiatives into our projects.Lean Six Sigma Yellow Belt (LSSYB)Being in the Construction Industry, going Lean in many cases when possible could be the right and only right thing to do. The LSSYB Journey enhanced my knowledge about Lean and how to apply it to different parts of any project or even in the office.Professional Scrum Master (PSM I & II), Scaled Professional Scrum (SPS)Although I do have experience in those areas and they might not be highly applicable to construction projects but going through this journey enhanced my knowledge and experience in how Inspection, Adaption and Delivering Incrementally helps reduce waste or errors and keep your product up to date and competitive within the market. Besides other areas when I use Scrum, I actually started applying the Scrum on some parts of our Real Estate Development projects to tell how well it would work and/or add value - You will be surprised, but the results were amazing. I might share this experience in details on another post or article.Professional Agile Leadership (PAL-I)This certification did open my eyes to some fact about building agile teams and how to empower them in addition to validating my experience in this domain.At the moment, I am pursuing the Agile Certified Practitioner (PMI-ACP) since I am being involved in Agile on so many levels and having more than 4 Years of experience, so I trust it will enhance and boost my knowledge in terms of how to apply agile concepts in projects and/or hybrid models (Agile – Traditional Models).In conclusion, the added value of knowledge combined with my background in Structural Engineering and experience helped shape my career path in a great way boosted my career advancement because as you can see, all of the certifications that I pursued are very much related to my field of expertise and line of business.
Rated 4.0/5 based on 5 customer reviews
The Added Value of Agile and Project Management Ce...

Over the years, I've heard so many different opinions and read so many... Read More