News, Analysis, Articles, and Resources for Certification Courses

Latest Posts

Themes, Epics, And The Art Of Writing User Stories

By Amrita Thavrani

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

Rated 4.0/5 based on 4 customer reviews

Blogs

112

Themes, Epics, And The Art Of Writing User Stories

by Amrita Thavrani
17 Jul 2018
2 mins read

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

By Olivia Kathleen

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.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.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.Often, 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.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.

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

Rated 4.0/5 based on 5 customer reviews

Blogs

316

3 Red Flags Agile Facilitators Should Watch Out Fo...

by Olivia Kathleen
16 Jul 2018

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

Individual Productivity : How Do You Measure It In Your Team ?

By Gisela Provenzano

It doesn’t matter what kind of product or services a business offers, it is essential to measure the employee’s productivity or performance, and it is more important to measure accurately as much as possible. Equally important is to use accurate performance measurements, which can reveal how well your business is progressing towards its goals and targets.Measuring employees’ productivity is a bit of a challenging task. A 2013 Gallup survey report conveys the interesting fact about why there can be a fall in performance of the employees. The reason is most of the employees are overwhelmed by smartphones, social media, personal emails, and the demands of their personal lives. Most employees find it difficult to produce the best work they could give. Lack of interest towards the work leads to the low performance.Measuring employees performance is one clear way to understand how skilled, engaged, and productive your employees really are.More often than not, as an Agile coach you might have been asked about measuring individual performance. Managers are worried about not being able to detect low performers in time and think of different strategies for doing it before it’s too late. And with “too late” I mean that it had a huge impact on the project or team.Individual productivity can be measured through different strategies or metrics. If you read on, you will understand better the importance of employees productivity followed by the outcomes the team gets.What can performance metrics bring for you?Performance metrics help you to create a snapshot of a team, which can be valuable when it comes to performance reviewsPerformance metrics can be used to plan ahead, by understanding what your team is capable of.Performance metrics give you the accurate measurements of how the process is functioning and provide a platform for you to improve further.For employees, performance metrics provide-The right feedbackHelp them understand where they stand, andLet them know areas where they can improveIt indeed gives you immense pleasure and a great feeling knowing you have strengths in a particular area.The applicability of VelocityOne of the common strategies any manager may think of is to use individual Velocity to solve this problem. And if the team is using Scrum, this idea may be rephrased as follows:“Evaluate those cases in which a team member is completing fewer story points than the rest of the team since that person must be a low performer”.If someone asked me this, my natural answer would be: it’s not a good idea!Will Velocity give you a better result?First of all, Velocity is not an indicator of performance:It just denotes the delivery rate of a specific team.It’s a team metric, not an individual one, and it serves for planning purposes. This means that any team may use it to understand how much work can be done in a specific period of time and, based on that, provide an estimate for a release date.You should also consider that velocity, as a team metric, cannot be established until the team has spent some time together. This means that, in most cases, the velocity of the first sprints of the team will NOT be high. In fact, I highly recommend setting the correct expectations in regards to this. If expectations are not correct, then for the team may seem as if they were not performing, when in fact they were just ramping up.On the other hand, measuring individual productivity by using velocity has more problems than advantages (in fact, the truth is that I haven’t been able to find any advantages so far). People may get confused by the results obtained when using this metric and the outcome may not be a good representation of reality.Why do I say this?Well, let’s say that John and Mark work in the same team and have similar experience and knowledge.John completes 20 story points and Mark only 10. This situation repeats over the following three sprints. Anyone may think that Mark is a low performer and that John is a genius! However, it may also happen that from the 20 story points that John completed each sprint, QA had detected over 100 bugs, but from the 10 that Mark completed, QA had only found 5. Now, which one is performing better than the other?For an individual, it’s not important to deliver a high productivity with a low quality, and less productivity with a high a quality adds an advantage to the employee as well as the team and the process too.This is just an example that demonstrates that velocity per se is not a good metric. Not to mention that if the team is aware that they are being measured by velocity, there is a chance that they increase their estimates to meet their goals. I can bet that you have already experienced things like this as well!We should not lose focus here. Remember that in an Agile world, what’s important is to constantly deliver value to the client: working software is the primary measure of progress.Customer is the KingWe should never ignore the importance of customer satisfaction. There are many factors that contribute to the success or failure of a business, customer satisfaction is one of them, it’s much essential to track this factor and work on improving in order to make customers more loyal and ultimately turn up them up into brand ambassadors.When you fail to care about them, in the same way, don’t have a hope or don’t expect them to care about your services or products.Forest Research declares 2017 as the year that businesses become customer-obsessed. So what is the secret?Providing “Value” to the customer.So, going back to the original problem, as a first step I would ask: what does low performer mean?We’ll all agree it may mean that:The person is not working at his/her fullest capacityThe person has not understood the vision of the projectThe person has not adapted to the team, orThe person has not been empathetic to the business needs,In this scenario, where there may be several causes for the problem, my recommendation would be that the team that is having the issue starts thinking of the big picture and work as a team.It means that the whole team is responsible for delivering value and that the whole team is committed to that. If something is going wrong with one of the team members, (and this probably implies low performance) the whole team needs to address it in the retrospective, or before, in the best scenario.Of course, the team may decide to take some metrics and use them to lead the conversation during the retrospective, metrics like: team velocity, number of bugs raised during the sprint, value added to the business, etc.Based on those metrics, the team may discuss options to improve and accelerate their process. Or, on the contrary, and in an ideal situation, the team may not need metrics since they are fully conscious of their processes and know how to constantly improve it.As you can see, if the organization is Agile, then every problem needs to be taken to the team. The team will know what to do with it. Managers will tend to ask for metrics and more metrics that help them understand the situation and fix it, but as Peter Drucker says-First of all, take the problem to the team. Then, let the team manage the problems and improve based on their own experience.And always remember, you are there to support the team and facilitate their improvements. To help them become a better version of themselves, do not become a roadblock for them.The last linesA well-measuring team productivity as well as a better handling of team results in providing a great customer service that satisfies both you and your targets as well. You get a proper revenue and make everyone happy, earn your brand name and enjoy great success.

Individual Productivity : How Do You Measure It In Your Team ?

Rated 4.0/5 based on 3 customer reviews

Blogs

230

Individual Productivity : How Do You Measure It In...

by Gisela Provenzano
13 Jul 2018

It doesn’t matter what kind of product or services a business offers... Read More

Search

Featured blog posts

Trending posts

Topics

Latest Posts

Themes, Epics, And The Art Of Writing User Stories

By Amrita Thavrani

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

By Olivia Kathleen

Individual Productivity : How Do You Measure It In Your Team ?

By Gisela Provenzano

Search

Trending blog posts

Featured blog posts

Trending posts

Topics

Latest Posts

Themes, Epics, And The Art Of Writing User Stories

By Amrita Thavrani

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

By Olivia Kathleen

Individual Productivity : How Do You Measure It In Your Team ?

By Gisela Provenzano