Search

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 <user type>, I want <a goal> because <why>.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?

253
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 <user type>, I want <a goal> because <why>.

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 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 talk about the immediate customer needs
  • 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 help in adding small features
  • 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.
 Acceptance CriteriaLet 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 this

Scenario: The registered user signs in with a valid username and password
“Given I am logged out of the website
and I am on the Sign-In page.
When I fill in the “Username” and “Password” fields with my valid credentials
and I click the Sign-In button
Then 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.

KnowledgeHut

KnowledgeHut Editor

Author

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.


Website : http://www.knowledgehut.com/

Leave a Reply

Your email address will not be published. Required fields are marked *

Suggested Blogs

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 ... Read More

The Personal Agile Transformation: An Agile Journey To Productivity

Much is made lately of the fact that some organizations are making the transformation to Agile, finding the greater emphasis on self-organizing teams, incremental deliverables and maximal business value compelling. However, whenever one reads about this transformation, it’s usually from the perspective of the organization and how Agile impacts it as a whole.  But while from the outside it would appear that an organization is some faceless monolithic structure, we know that it is comprised of living, breathing people who themselves deliver the goods and services that the organization provides. And so, it seems important to consider what the impact is on those who must deal with their own personal Agile transformation.  I have been performing traditional project management for over twenty years. I teach project management as well, and I’ve always been fond of telling my students that project management is, like accounting, a mature profession. Accountants talk about debits and credits and the only thing that really changes periodically is the tax code. The lingua franca of project management is, and for many years has been, artifacts such as Gantt charts and Work Breakdown Structures.  But to a great extent, the ground has started to shift under the feet of traditional (plan-driven or waterfall) project managers, especially in the last few years. This is because the Agile approach, initially defined in a manifesto in 2001, has really begun to establish itself in corporations. Not, I would say, to the extent that it is replacing traditional methods and not everywhere.  But significantly enough that project managers now need to be not only conversant in it but must also begin to consider being trained in it and getting some experience. (Its greater recognition in that bastion of traditional project management, PMI’s Project Management Body of Knowledge, Sixth Edition, is a fairly significant development).  On a personal level, I got my Certified Scrum Master certification in early 2013 but never used it, at least not initially. It wasn’t so much that I was opposed to Scrum as much as that I was working in traditional project management and hadn’t really witnessed first-hand the revolution under my own feet.  But gradually I began to realize that there was going to be a significant shift in the direction of the use of Agile and that in order to stay conversant – and, I might add employed – it would be necessary to start getting exposed to Agile projects and working in them. And in thinking about it, I realized that perhaps the very first thing I had to contend with in Agile was the fact that not only is the project manager role not quite as significant, in fact, there is no defined PM role as such. In the Scrum variant, there are only three defined roles – Scrum Master, Product Owner, and Development Team. When I got my Scrum certification, I realized even then that it was a different type of role. As a project manager, I might – and should – do all the planning with my team. But when it comes time to decide who did what and when, that was always my job. It is very much of a command and control structure. And not only did I expect to lead the team, the team expected to be led. But in Agile it’s quite different. In that role, I am much more of a facilitator or coach than I am a driver of the team. The team is self-organizing, meaning that while I can help remove impediments for them, it is not my job to tell them what to do as such. It is their job to figure out what to do as a team and for the Scrum Master to facilitate and coach. Find some useful tips on how to succeed with your Agile transformation below- This is a major shift, not only for the project manager but also for the team. For the project manager, he or she must stop being directive and start being facilitative. For a lot of PMs, this is a very challenging transition. They don’t know how not to direct. And as likely as not, if they have been a PM for a long time, they are very much used to using a scheduler such as MS Project. But a Scrum team doesn’t necessarily need such a tool, preferring workflow tools such as Jira to track progress. The challenge is that the traditional project manager must hold back on telling the team what to do when they ask. He or she can remove impediments when they arise. But his or her best advice when asked what a team member should do is “take it to the team.” In a sense, he or she has to rethink what he knows and throw some of his or her training out the window.  Be a Scrum Master, Not a Scrum Manager https://t.co/ohOBBzH5Lb #agile #scrum #dev @HyperRTs @DNR_CREW pic.twitter.com/XrmsCAdzwK — Seth G. (@Nicko_iCorplife) October 14, 2017 And it isn’t just the PM that may have a problem adapting to this new reality. Imagine the team member who is used to being told what to do in a hierarchical situation. Now he or she is faced with, to a certain extent, being self-directed. Some prefer not to go through this experience.  And while Agile can be used for a variety of projects, it still tends to be heavily used in software development environments. And some developers, for example, used to working alone, are now expected to meet every day not only with the team but with the business. For some, this is outside their comfort zone. I spoke to a woman at an Agile conference who advised me that several developers on her team asked to be moved or left the company when Agile came in. I think the main takeaway here is embracing change and adapting. (Ironically, hallmarks of Agile itself.) Some people just prefer to do things the way they’ve always done them. And then when change overtakes them – as surely it is doing in an Agile world – they are unable to make an adjustment and wind up on the outside looking in.  Once I realized that I needed to get into this world, I made this transition not only by getting trained but by adopting an Agile mindset. (Which is what Agile coaches help teams do.) I started reading everything I could get my hands on, networked as much as I could and then when the time came, leveraged that knowledge and my years in project management into a role within a company that, while Agile-ready, still saw the value of both approaches. And when I let go of the need to be in control – and realized I needed to be a coach and facilitator -  I found that things just fell into place.
Rated 4.0/5 based on 22 customer reviews
The Personal Agile Transformation: An Agile Journe...

Much is made lately of the fact that some organiza... Read More

How Not to be Agile – 2. The Business Case

Is Agile Everything?‘How Not to be Agile’ may seem a strange title for the blogs mentioning about how good Agile is!The benefits of adopting the Agile methodology are well documented everywhere.  What I intend to do over these series of articles is to share with you the misinterpretations, omissions and mistakes that people make. This significantly reduces the potential benefits when an organisation, or part of it, embark on an Agile Transformation.Agile Transformation is not an easy task! Though the ‘mechanics’ behind the Agile frameworks are relatively straightforward to implement, people have trained adequately. However, the root cause of all the troubles that I met is inadequate training and/or coaching of everybody involved with the Agile Transformation including the development people as well as the senior and middle management, both business and technical.Last time, I discussed the potential pitfalls of not having a suitable and visible Vision and Objectives for whatever it is that we are trying to achieve, be it a new product, a major change to an existing product or the Agile transition itself.This time, I will cover some of the omissions, misunderstandings and malpractices that I have come across with respect to the Business Case; an overall product development ‘document’ with which we can track whether the ongoing development is likely to meet the business value outlined or specifically stated in the development Objectives for a reasonable cost; it is no use developing a product for $1 million dollars if it will take 10 years of product use before it pays for itself.I will start with a description of an Agile Business Case and then give examples of what has and could go wrong.What is the Business Case?Having achieved an agreed Vision and Objectives, the business stakeholders and development team need to quantify the business value that is expected from the product, in what timescale, and the estimates of how much it will cost to develop so that that the business stakeholders can determine whether the development is justified from a business point of view.These estimates are recorded in the Business Case; a cost-benefit analysis. In the past, in an effort to reduce development business risk as much as possible, some companies produced a detailed, task level,a project plan with all the ‘who will do what and when’, factoring in known team member holidays etc.  By this means, they hoped to establish the probable costs of the development with a high degree of accuracy.  However, I have never seen the expected business benefits undergo such a rigorous analysis.Also, I have never seen the Business Case updated periodically during the development so that it can be determined whether the development is still justifiable.This way of producing a Business Plan usually involves a ‘development expert’ to do the technical estimations and takes a significant amount of time during which no business benefit is being accrued.What is an Agile Business Case?“Therefore, ‘experts’ are asked for their opinion about probable or possible costs for different ways of solving the problem:Develop the product from ‘scratch’ – usually the most expensive optionUse an existing product as a ’base’ and modify/configure it – the next most expensive optionOutsource the development – ‘passing risks to some other company’ – the costs can vary significantly depending on the contract type.From these ‘guesstimates’, the development Sponsor can take a decision as to which development option to take.  I will discuss Agile Roles in a later article.There is always another option for the Sponsor to take – ‘Do Nothing’; especially if the probable cost-benefit analysis indicates little Return-on-Investment.If the initial, ‘guesstimate’, Business Case cost-benefit analysis indicates that it may be worthwhile continuing with development, development continues.”What is Agile Business Case Lifecycle?Once the initial Agile Business Case has been created it is not ‘set in stone’; like most other things in an Agile environment, it is subject to change as we learn during the development.  Indeed, I use a set of development ‘document’ templates, which includes making a business case for Agile, that all have ‘This is Subject to Change’ printed in red at the top and bottom of each page.Post Product Backlog CreationThe Product Backlog, which I shall discuss in my next article, is a list of ‘requirements’ that have been ordered by business value and estimated.These estimates, that have been done by the development team, can replace the costs section of the initial Business Case. The initial Business Case expected benefits can be assessed by a wider stakeholder population and either confirmed or modified.The cost-benefit analysis for the modified Business Case values can be used to, again, assess whether it is advisable to continue the development, modify the Vision and Objectives to obtain a viable Business Case or cancel the development.The time taken from establishing the Vision to achieving this first modified Agile Business Case should be no longer than 4 to 5 weeks; usually, a lot shorter time than is usually taken in a traditional product development environment.At the End of Development TimeboxesA Development Timebox is the short, 2 to 3 week period during which the development team completely develop a subset of the ‘requirements’ and what has been developed demonstrated to the relevant stakeholders.  Most of you will recognise this as the definition of a Sprint from Scrum; other Agile Frameworks use different names; I will use the term Sprint during the rest of this article because it is quicker to type!It is recommended that the Agile Business Case be ‘reviewed’ at the end of each Sprint, during the Sprint Review, for the first few Sprints; it is during these first Sprints that the learning curve is steepest. The estimated costs against the actual costs can be assessed and the Agile Business Case updated if necessary.  Obviously, assessing the actual benefits accrued at this early stage in development is almost impossible.  However, a view can be taken on the new cost-benefit analysis as to whether to continue development.Remember:‘Fail Fast’Once the initial learning has been done, most organisations revert to reviewing the Agile Business Case during the Increment Reviews, done just before a group of functionalities is placed ‘live’; probably every 2 or 3 months.Case Study 1:Many years ago, I was asked to help a team who were building a financial products sales system to replace a company’s current system.  The ‘need’ that prompted this development was regulatory in that there had been ‘mis-selling’ of some of the financial products and the government had told the whole sector that they had 6 months ‘to clean up their act’.The company’s current system was based on an ageing mainframe and it was decided that as well as trying to incorporate new regulatory business rules into the sales system, the whole process would be ‘transferred’ to a system using ‘modern’ technology so that additional sales processes could be incorporated, taking advantage of the capabilities of the new technology.The company mitigated some of the huge risks that they were taking on by outsourcing the development on a fixed price basis; the outsource company decided that ‘Managed RAD’ (the precursor of Agile) was the way to go; I was helping the outsource supplier company team.The ‘Vision’ was clear:“To develop a financial products sales system that complies with Government regulation in 6 months so that the company can continue to sell financial products”There was an onsite, senior salesman from the client company to give the requirements for the new system; the equivalent of a Scrum Product Owner.Unfortunately, no one had taken the time to produce a Business Case; it was obvious wasn’t it? ‘New system in 6 months or die’!The prevailing culture within clients and business management at the time was the ‘WISKY’ mentality; “Why Isn’t Someone ‘Koding’ Yet”.That and the 6-month deadline led the team to cut corners on the preparation.  Some rudimentary ‘As-Is’ business process modeling had been done to identify where the sales process needed to be modified to include the regulatory requirements as well as where the new parts of the sales process needed to be inserted.The product Owner insisted that as much of the ‘As-Is’ had to be in the new system as well as the new parts.The team decided to go for the ‘low-hanging fruit’ approach, developing the easy and quick parts first; unfortunately, these did not include the regulatory requirements nor the new sales processes.After 2 months of development, the team released the first prototype to the client company to get feedback.  The client was very concerned that there was no sign of the regulatory requirements or new sales process and that the team had developed ‘As-Is’ processes that had been in the old system that were there because of the limitations of the old technology, such as overnight batch processing of data.It was at this point that the client was considering cancelling the development contract but they were 2 months closer to the important deadline so it was decided to bring someone in that could turn the ‘mess’ around; that someone was me.I started by investigating the Vision and establishing what was the minimum that was needed in the remaining 4 months.  It was decided that a system to support the end-to-end sales process of just one of the financial products, incorporating the regulatory requirements, without any of the new ‘bells and whistles’ would satisfy the regulators and the client company could continue trading.The ‘Product Owner’ was replaced with a less experienced salesman who was not as ‘wedded’ to the old sales process as the previous Product Owner.We established and prioritised the development objectives and put together a Business Plan that was used every week as a means to assess development progress toward the highest priority objective of getting the new regulatory requirements incorporated into the sales process.The new system was ‘finished’ one month early and was demonstrated to the regulators who had high praise and used the new system as a benchmark with which to assess the new systems of other companies in the same sector.During the month left before the deadline other high priority financial products were added to the system; the client deciding that they would suspend sales of the less important products until they too could be added to the new system.Lessons:1) The apparent lack of time always drives people to ‘cut corners’, especially in the preparation.  How many window and door frames have you seen that look ‘rough’ because the surfaces were not prepared adequately before applying the top coat of paint?  In this case study, some of the people were almost paranoid about the ‘New system in 6 months or die’ so that they focused entirely on the time aspect with little consideration about what the original Product Owner was asking them to do.As a consequence, the team produced a less than satisfactory first prototype.2) Don’t leave the requirements set to one person however experienced they are; the question of ‘do we really need to develop the whole of the new system in 6 months?’ would probably have been asked in the early stages if the requirements setting had been done by a group of people including some developers.3) The lack of prioritised development objectives and a Business Case to assess development progress toward the highest priority objective(s) aided the ‘low hanging fruit’ approach adopted by the outsource company enabling them to effectively waste most of the 2 months work in producing the first prototype.4) On a positive note, however, the incremental delivery nature of Agile had allowed the team to ‘fail fast’.  If the team had continued development without customer feedback for all of the 6 months, who knows what sort of system that they may have produced.Case Study 2:I was asked to do an Agile audit in an organisation because one of the senior managers was concerned that he was not seeing the benefits of ‘being’ Agile that were ‘sold’ to him by a chosen ‘partner’ development agency.The development was a programme of work to integrate 12 disparate systems, ‘inherited’ by the organisation by the acquisition of other organisations; the overall aim was to ensure consistency of data across the organisation and allow the use of a data warehouse for decision making.The programme was using an in-house Agile framework based on the DSDM framework. The anti-Agile practices across the programme that I discovered during the audit could make the definitive guide on how not to be Agile.However, I will confine my comments to the consequences of the lack of knowledge on building the Agile Business Case for just one of the projects.The project ‘Vision’ was to automate many business processes that were currently being done manually.  When I arrived, the project had been running, on and off, for about 18 months and had not delivered anything.  I asked what the project costs to date were and was told that they were in the order of £1 million but this could not be verified because cost accounting in the organisation and for the programme was very ad-hoc.The team was struggling with defining the details of some of the User Stories; several attempts had been made during several workshops to finalise these details before development in one or more Sprints.I decided to sit in on one of these workshops to see what was happening.A ‘Systems Analyst’ was sat in front of her laptop, not shared with the rest of the workshop, and asked questions of the business representatives.  They discussed their answers to the questions which mostly were preceded by ‘It depends’.  I asked if any prototypes had been attempted for the User Story under consideration and was told ‘we don’t do prototypes because we do not have any prototypers’.  I then asked the stupid question ‘What is a prototyper?’.  The obvious answer – someone who prototypes!  It became obvious that the organisation believed that prototypes had to be produced in code, rapidly.I went to the whiteboard, drew a large rectangle and asked the business representative what they expected to see on a screen, focusing on the most used path through the User Story.  In 20 minutes we established the ‘core’ data and business rules for the User Story; it had taken 3 months of sporadic workshops not to get that far.This workshop anecdote led me to ask how this ‘analysis paralysis’ situation had come about.  The answer was that the team had ignored one of the basic Agile framework ‘rules’ that development takes place in short, 2 to 3 week, Sprints; the aim of a Sprint is to develop, as fully as possible, a group of User Stories so that they are potentially shippable.  As part of the Sprint or Increment Reviews, the business should assess the Business Case to see if it remained viable.Apart from not running Sprints as recommended, the team had a less than adequate Vision and no Objectives on which to base a Business Case.  For some reason, which I was never able to fathom out, nobody in the programme or the rest of the organisation was questioning the lack of development progress for this project or the amount of money they were spending for no visible benefit.To cut a very long story short, when an adequate Vision and Objectives were created and a Business Case put together, the business realised that what they were trying to achieve was fundamentally flawed and the project was cancelled.LessonsDespite the poor workshop processes and abandonment of key Agile development practices, the fundamental problem with this project was a lack of adequate Vision and Objectives with which to construct a Business Case by which assessment could be made of development progress toward realising the expected benefits at a reasonable cost.When Vision, Objectives and Business Case were in place, the business realised the futility of the efforts so far and therefore had allowed a waste of £1 million by not having them earlier.ConclusionThese 2 case studies illustrate the worst cases of no Business Case that I have experienced; there are many others.Having tight deadlines or even no apparent deadline does not excuse the lack of sufficient and proper preparation.I discussed the Vision and Objectives issues in the first of this series of articles but these should be used to build a Business Case that can be used to assess development progress toward meeting the expected Objectives for a reasonable cost; developing User Stories is not the aim of Agile; the aim is to develop the right User Stories in the right order.
Rated 4.0/5 based on 0 customer reviews
How Not to be Agile – 2. The Business Case

Is Agile Everything?‘How Not to be Agile’ may ... Read More

other Blogs