The most difficult part of discovering and analyzing requirements on agile teams is determining how much detail is needed and when we should discuss the details. Early advocates of agile approaches, like SCRUM, emphasized a high level product vision at the beginning of development and then quick, lightweight user stories to support the vision detailed before each sprint. They suggested that we don’t need to get into any details until sprint planning. But as more and more teams are attempting to use agile approaches, the challenges of this requirements approach are exposed.
I love the end of the year articles about the top ten movies of the year, or top ten books, and also the New Year predictions like “12 trends to watch in 2017”. Every year during the holidays, I find myself reading these top ten lists and predictions but this year I began thinking about why they are enjoyable, and whether or not they are a good use of my time. As the leader of a book club, the top ten books of the year lists are a great source of ideas for my group so my time reviewing them is useful. But what about from a work and career perspective; should I be spending time reading about the top ten training trends from 2016?
I came across a new phrase last week, which I really like: “aggressive transparency”. I saw this phrase in the Project Management Institute, Inc. exposure draft of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. It is used in the Project Stakeholder Management chapter referring to the fact that agile approaches strive to be very transparent so that stakeholders always are aware of project progress. I liked the phrase and searched on it to see if I could find where it originated.
We teach prioritization techniques in many of our classes and many of the conversations we have at conferences and meetings are about how challenging it can be to get a group of people to agree on project priorities or even individual aspects of a product. As I was working on my 2017 strategic plan, I decided to write a short post on prioritization and metrics.
As a program manager at RMC Learning Solutions I have to prioritize projects and make recommendations to my management. We have many ideas for new courses, products, and services which are competing for our time. Prioritizing requires us to assess the expected value of an idea against its expected cost and then compare it to other ideas.
I’m going to the BBC Conference (Building Business Capability) next week and am really looking forward to the sessions, the exhibit hall, and networking with other professionals. I realize that I am fortunate to be able to attend several conferences each year, but I know many people are lucky if they get to go to one. If you are going the BBC or another conference, make the most of it. Here are some tips for preparing to attend a conference which will help you get the most value.
This is the fifth and final post in a series about the PMI-PBA® certification. The last exam area is the Evaluation domain and includes the work necessary to make sure the solution is ready for the stakeholders, and that it delivers the value expected. This is the last domain in the PMI-PBA exam content outline which includes Needs Assessment, Planning, Analysis, and Traceability and Monitoring. Solution evaluation is where all of the work of the project comes together. Business analysis work in this domain assures that the solution is ready for use in the business area. To make sure it is ready, it must be thoroughly tested, the end users must be ready to use it, and the organization must be prepared for its impacts. Business analysts are important team members in this work.
Paying attention to the details is good business analysis
How many little mistakes do you see?
I open the newspaper in the morning and see a typo. I open my email and see a grammatical error. I go to a web site and a menu button doesn’t work. How many “little mistakes” do you see in a day? Corporations are pushing employees to work faster and get products to market sooner. Is this agile or is this sloppy? Many companies sacrifice analysis and attention to detail to increase revenue but it won’t pay off in the long run.
In the United States (and I am sure other countries), we hear lots of complaints about the cost of regulations. This is especially true during a presidential election year. The paradox of regulatory complaints is that some candidates argue complying with regulations is too costly, while others argue that the cost of not having enough regulations risks the safety of our community. Regulatory costs (or the costs of lax regulation) are not just monetary but also environmental, societal and can result in a degradation of our values and way of life (e.g. lead in our water system). I would like to suggest that more analysis would help curb the costs of regulation.